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PREFACE 
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FOREWORD 


The  United  States  Coast  Guard  has  recently  been  responding  to 
more  than  40,000  distress  incidents  per  year  in  the  coastal  and  inland 
waters  of  the  continental  United  States  which  are  under  their  juris- 
diction. They  have  aided  recreational  boaters,  commercial  fishermen, 
and  other  individuals  in  maritime  distress,  preventing  or  limiting 
loss  of  life  and  destruction  of  property. 

Projections  of  future  recreational  boating  shows  an  average 
increase  of  4.4%  per  year*.  This  increase  alone  might  soon  impose 
severe  demands  on  Coast  Guard  services  to  be  rendered  to  the  general 
public.  For  this  and  similar  reasons,  the  Coast  Guard  must  make  strategic 
plans  for  the  Search  and  Rescue  (SAR)  missions,  with  regard  to  procurement, 
allocation,  and  organization  of  resources  within  budgetary  constraints  for 
any  selected  time  frame. 

The  tools  of  management  science,  systems  analysis  and  operations 
research  readily  lend  themselves  to  the  type  of  problem  represented  here. 
Accordingly,  the  National  Bureau  of  Standards,  in  a joint  effort 

with  the  Coast  Guard**,  has  developed  a Search  and  Rescue  Simulation 
Model  (SARSIM)  to  assist  Coast  Guard  management  in  its  approach  to 
planning  for  future  SAR  activities. 

*"Long  Range  Forecase  of  Activities  in  the  Marine  Environment  with 
Implications  for  Planning  Coast  Guard  Search  and  Rescue  Operations", 
National  Planning  Association,  Washington,  D.C.,  Feb.  22,  1971, 

Executive  Summary  p.  10 

**Karp,  S.S.  and  T.T.  Matteson,  "The  Integrated  Team  Concept,  of 
Simulation  Model  Development",  Proceedings  of  the  1971  Summer 
Computer  Simulation  Conference. 
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SARSIM  is  a highly  flexible,  user-oriented  model.  It  simulates 
Coast  Guard  response  to  an  input  caseload  scenario,  i.e.,  people  and/or 
property  in  distress.  The  automatic  summary  output  from  the  model 
(e.g.,  response  times,  resource  utilization  statistics,  etc.)  gives  the 
user  considerable  insight  for  judging  the  effectiveness  of  the  SAR 
system  with  regard  to  each  input  scenario. 

The  user  is  offered  a variety  of  modes  in  which  to  operate  the 
model.  For  example,  he  can  prepare,  automatically,  a multitude  of 
client  demand  scenarios.  He  can  perturb  the  SAR  resource  inventory, 
i.e.,  vary  the  number  and  classes  of  resources,  their  physical  capabilities, 
their  deployment  (location),  and  manning  levels.  He  may  also  choose  to 
exercise  the  model  with  different  server  disciplines  (resource  assignment 
schemata).  In  addition,  the  user  can  supply  criteria  to  be  applied  to  the 
simulated  case  history  output  for  additional  optional  analysis. 

In  simmary,  SARSIM  offers  flexible,  built-in  capabilities  to 
aid  Coast  Guard  decision  makers  in  developing  long  range  strategic  plans 
to  carry  out  the  SAR  mission. 
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Part  I - Introduction  and  Background 


1.  Problem  Definition 
Need 

Because  of  the  rapid  and  continuing  growth  of  marine  activity, 
especially  in  recreational  boating,  combined  with  the  constraints 
imposed  by  national  budget  allocations,  the  Coast  Guard  has  found  it 
necessary  to  examine  its  current  readiness  postures  and  operating 
policies  and  to  project  future  Search  and  Rescue  (SAR)  Force  Level 
Requirements  on  an  integrated  resource  basis.  That  is,  the  Coast 
Guard's  aircraft,  cutters  and  shore  stations  with  their  associated 
boats  must  be  considered  simultaneously  as  a system  in  order  to 
plan  properly  for  the  entire  SAR  mission. 

In  order  to  provide  insight  to  evaluate  the  system  comprehensively 
on  a unified  basis,  a methodology  had  to  be  developed  and  associated 
criteria,  or  measures  of  effectiveness  had  to  be  created  to  help 
analyze  the  various  SAR  mission  alternatives. 

Typically,  management  is  concerned  with  determining  the  best 
mix  of  resources  to  accomplish  the  SAR  mission,  simultaneously  answering 
such  queries  as: 

How  many  resources  of  each  type  should  be  procured  (or 
phased- out)? 

© 

Where  should  the  resources  be  deployed  to  achieve  maximum 
effectiveness? 

What  are  the  most  cost-effective  crew  manning  readiness  levels 
for  each  Coast  Guard  station,  for  various  times  of  year,  week, 
day? 
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» What  are  the  differences  among  various  operating  tactics? 

• What  are  the  effects  on  the  system  of  the  introduction  of 
new  resource  types,  having  increased  capabilities? 

9 What  are  the  effects  of  introducing  different  organizational 
structures,  such  as  grouping  the  facilities  of  store  stations? 
Objective 

The  initial  objective  of  this  study  was  to  assess  the  feasibility 
of  various  methodologies  to  assist  Coast  Guard  management  in  answering 
the  questions  posed  above;  and  given  its  feasibility,  to  propose  the 
design  for  the  most  promising  methodology.  Underlying  this  goal  was 
the  study  team's  desire  to  provide  management  with  a highly  realistic, 
flexible  tool  to  examine  the  SAR  system  under  a wide  range  of  conditions. 
Since  direct  experimentation  with  the  system  is  probably  infeasible  be- 
cause of  its  potential  danger  to  human  life,  it  quickly  became  apparent 
that  a model  of  the  SAR  system  would  most  likely  be  necessary. 

Description  of  the  SAR  Process 

The  Coast  Guard’s  search  and  rescue  activities  constitute  a fairly 
complex  process,  characterized  by  heterogeneous  classes  of  clients  in 
distress.  Furthermore,  depending  on  the  type  of  distress  and  the  urgency 
with  which  assistance  is  required,  there  may  be  available  a wide  variety 
of  types  of  SAR  resources  to  serve  the  clientele.  Resources  differ  in 
capability,  related  to  their  physical  attributes  and  the  environmental 
conditions  at  the  time  of  an  incident. 

SAR  incidents  may  involve  peril  to  people  or  the  threat  of  damage 
to  or  loss  or  property.  Occurrences  of  distress  incidents  tend  to 
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cluster  at  "preferred"  locations  or  peak  time  periods,  but  are  generally 
widely  enough  distributed  around  the  average  times  and  places  that  they 
seem  to  occur,  to  all  intents  and  purposes,  at  random.  The  needs  for 
assistance  also  vary  widely,  and  include  rescue  of  personnel  in  the 
water,  search  for  lost  vessels,  extinguishing  of  fires,  dewatering  of 
flooded  vessels,  help  with  repairs  or  replacement  of  damaged  material, 
or  towing  to  safety. 

The  Coast  Guard  resources  dedicated  to  SAR  are,  for  the  most  part, 
located  at  shore  stations  along  coasts  where  distress  incidents  are  most 
often  experienced.  These  stations  are  grouped  into  about  a dozen 
major  districts*  and  several  minor  districts  (which  are  either  geo- 
graphically small  or  which  serve  relatively  few  cases) . The  major  districts 
contain  from  30  to  50  stations,  called  Operating  Facilities  (or  OPFAC's), 
at  which  are  stationed  about  80  - 150  rescue -capable  units  (resources) 
categorizable  into  some  15  - 20  resource  types.  Short  stations  with 
small  boats  handle  the  bulk  of  the  SAR  incidents  encountered.  They  are 
supported  by  fixed-wing  aircraft  and  helicopters  at  nearby  Coast  Guard 
air  stations,  as  well  as  long-range  aircraft  which  might  be  stationed 
at  considerable  remove  outside  the  district.  Covering  Coast  Guard 
cutters  are  also  available  to  assist,  either  from  shore  stations  or  while 
operating  independently  on  SAR  patrol  at  sea. 

The  SAR  process  may  be  viewed  as  a spatially  distributed  queueing 
system  in  view  of  the  areal  extent  of  SAR  cases  and  the  decentralized 

*Coast  Guard  districts  generally  consist  of  several  contiguous  states 
and  are  numbered  like  U.  S.  Naval  districts. 
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deployment  of  Coast  Guard  resources.  Coast  Guard  receipt  of  notifi- 
cation of  a distress  situation  corresponds  to  the  random  arrival  of 
a client  ("customer"  in  the  text  book  sense) . The  resources  at  the 
station  receiving  the  notification  may  or  may  not  be  capable  of  re- 
sponding to  the  call  for  assistance,  depending  on  the  combination 
of  pertinent  factors.  These  include  the  location  of  the  incident 
relative  to  the  station,  the  characteristics  of  the  unit  in  distress, 
the  nature  and  seriousness  of  the  distress , the  environmental  con- 
ditions, and  the  physical  and  operational  characteristics  of  the  local 
resources.  Thus,  for  example,  a small  boat  might  not  be  capable  of 
operating  effectively  in  high  seas , or  might  not  be  able  to  tow  a larger 
boat. 

Capable  resources  assigned  to  a station  might  not  permit  response 
to  a call  for  assistance  if,  for  example,  they  were  all  busy  on  other 
cases,  or  "down"  for  maintenance,  or  not  fully  manned.  Consequently, 
availability  at  the  time  of  call  must  be  considered  along  with  capability. 

Dependent  on  established  policies,  resources  from  nearby  shore  sta- 
tions (or  covering  air  stations  and  cutters)  may  be  called  upon  to 
render  the  necessary  SAR  services.  Whatever  policy  has  been  set,  a 
capable  resource  is  assigned  if  such  is  available.  If  assignment  cannot 
be  made,  the  client  will  perforce  wait  (in  a queue,  as  it  were)  until 
the  earliest  feasible  assignment.  However,  if  the  seriousness  of  the 
situation  warrants,  ongoing  service  to  an  earlier  arrival  might  well  be 
interrupted  to  attend  to  a higher  priority  case.  At  each  station 
several  queues  may  exist  simultaneously,  each  containing  cases  of  the 
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same  priority  in  the  order  of  their  arrival  into  the  system.  The  highest 
priority  queue  will  be  served  as  capable  resources  become  available,  and 
in  the  order  in  which  cases  arrived.  Only  after  that  queue  has  been 
emptied  will  lower  priority  cases  be  handled.  (Provisions  may  also 
be  made  to  review  the  priority  of  waiting  cases  and  raise  it,  if 
necessary  or  desired.) 

It  is  clear  from  the  foregoing  abbreviated  discussion  that  there 
are  compound  interactions  among  the  clients  (i.e.,  the  cases  of  distress) 
who  enter  the  system,  the  inventory  of  local  resources  at  the  notified 
station  and  their  status,  neighboring  and  covering  stations  and  the 
status  of  their  resources,  priority  interrupt  and  resource  assignment 
policies,  the  ambient  conditions  at  sea,  and  other  applicable  factors. 
These  interrelationships  contribute  to  the  difficulty  in  selecting  an 
approach  for  modeling  of  the  SAR  process , and  hence  had  to  be  examined 
in  considerable  detail  to  assure  a reasonably  accurate  analytical 
facsimile. 

Scope 

The  study  leading  to  the  simulation  model  reported  herein  was 
limited  in  scope  to  include  only  the  SAR  mission  of  the  Coast  Guard.  Its 
other  missions  such  as  law  enforcement,  aids  to  navigation,  merchant 
marine  safety,  etc.,  are  preemptible  by  a SAR  incident  and  can  be 
reasonably  excluded. 
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Only  surface  vessels  and  air  resources  have  been  considered  in 
the  study.  More  specifically,  cases  which  cannot  be  aided  by  the 
above  categorized  resources,  (such  as  "overdues"  located  through 
communications  checks,  cases  requiring  medical  advice,  or  cases  aided 
by  a station's  motor  vehicle)  are  not  considered. 

The  study  was  to  be  open  ended  relative  to  time  frame.  That  is, 
the  end  product  methodology  had  to  be  futuristic  in  concept  such  that, 
for  example,  the  projected  demand  over  a ten  year  period  could  be 
applied  and  the  force  requirement  determined;  or  new  equipment  and 
operating  techniques  could  be  considered  without  redesigning  the  method- 
ology. 

However,  in  the  interest  of  providing  meaningful  data  to  the  Coast 
Guard  management,  some  macro-level  of  organization  is  preserved.  By 
using  the  Coast  Guard  district  as  the  system  boundary  in  examining  the 
problem,  pertinent  variables  could  be  considered  in  more  detail  than, 
for  example,  if  the  entire  East  Coast  operation  were  modeled  as  a whole. 
The  selection  of  the  district  level  of  organization  as  a boundary  is 
further  justified  by  the  relative  independence  of  operations  from 
district  to  district.  To  be  realistic,  however,  particular  interdistrict 
activities  are  also  considered  simultaneously  when  examining  the  system 
on  an  intradistrict  basis.  This  approach  was  an  obvious  requirement 
since  certain  long-ranged  aircraft  resources  are  made  available  to  handle 
cases  along  a single  coast.  In  bounding  the  problem  in  such  a fashion, 
no  loss  of  important  interaction  among  the  districts  is  encountered. 
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Of  course,  a subset  of  the  model  should  be  exercisable  so  that  if 
the  user  chose  to  apply  the  methodology  to  an  organizational  level  of 
lesser  magnitude  than  the  district  (e.g. , a single  station),  he  might  do 
so,  provided  that  he  recognizes  that  the  results  are  localized  to  that 
level.  In  short , simulation  at  any  organizational  level  is  permitted,  but  the 
limitations  imposed  by  the  required  level  of  detail  for  meaningfully 
modeling  the  search  and  rescue  system,  the  level  of  station  interaction 
and  queueing,  and  the  available  computer  storage,  all  contribute  to 
the  definition  of  these  bounds.  Further,  these  last  two  constraints 
also  place  an  upper  bound  on  the  number  of  cases  that  can  be  examined 
simultaneously,  thus  bounding  somewhat  the  time  frame,  (e.g.,  a month, 
a peak  period)  of  a single  model  exercise. 

The  study  approach  does  not  encompass  the  causative  factors  involved 
in  SAR  cases.  Boating  safety  education,  although  important  to  the  entire 
SAR  problem,  is  not  considered  in  the  study,  as  the  incidences  are 
taken  as  given.  The  objective  here,  then,  is  to  examine  alternative 
ways  of  serving  a given  forecast  caseload  so  that  the  Coast  Guard  can 
compare  the  performance  and  cost  of  each  alternative  as  part  of  its 
long  range  planning  and  evaluation  effort. 
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2. 


Alternative  Methodologies 


The  recommendation  to  examine  the  feasibility  of  developing  a 
model  of  the  SAR  system,  with  emphasis  on  measuring  resource  utilization 
on  an  integrated  basis , was  made  to  Coast  Guard  management  (as  reported 
in  the  Second  Interim  Report  on  a Multi-year  Special  Analytical  Issue 
Study,  June  1969)  by  the  Plans  Staff,  in  the  Office  of  Operations, 

USCG.  This  group  had  already  developed  a simple  queueing  model  for  a 
single  Coast  Guard  shore  (small  boat)  station,  applying  the  Poisson 
arrival s/Exponential  service  time  queueing  formulations  to  determine 
the  number  of  servers  (boats,  crews)  required  to  provide  a given  level 
of  service  for  that  station's  caseload.  These  shore  stations  have  a 
relatively  homogeneous  set  of  servers  (small  boats)  and  a high  incidence 
of  arrival  of  the  typical  case,  making  the  closed  form  model  a reasonable 
predictive  tool  for  resource  analysis  for  a single  shore  unit. 

The  Technical  Analysis  Division  at  the  National  Bureau  of  Standards 
was  called  upon  to  examine  the  entire  integrated  SAR  problem,  offer 
its  recommendations  as  to  the  proper  methodology,  and  subsequently  to 
complete  the  study  as  a joint  endeavor  with  the  Coast  Guard.  Three 
basic  methodologies  became  apparent  to  the  study  team.  The  first 
approach  is  to  perform  certain  well  planned  experiments  directly  with 
the  SAR  system,  collect  empirical  data,  and  measure  the  effects  of 
the  experiment.  Second,  the  analytical  model  approach  may  be  applicable, 
if  the  client/server  relationships  can  be  extended  to  represent  the 
integrated  SAR  system  in  closed  form.  A third  approach,  the  development 
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of  a large  scale  simulation  model,  could  be  undertaken  so  that  indirect 
experiments  might  be  undertaken  with  a realistic  model  of  the  SAR 
system. 

To  apply  the  direct  experimentation  approach  in  the  real  world 
is  extremely  risky  for  the  Coast  Guard  from  two  viewpoints.  First, 
the  chances  of  getting  useful  results  are  not  very  promising  because 
of  the  difficulties  of  conducting  closely  controlled  experiments  on 
the  operational  system.  Coast  Guard  experience  indicates  that  field 
personnel  do  not  always  comply  with  the  experimental  rules.  For 
example,  when  a case  is  to  be  queued,  often  an  additional  resource 
would  be  dispatched  to  service  it  ’’illegally"  to  avoid  any  possible 
risk.  More  importantly,  however,  the  risk  associated  with  the  possible 
loss  of  life  or  destruction  of  properties,  when  the  system  is  undergoing 
experimentation,  is  one  that  could  carry  serious  moral,  legal  and 
political  implications,  each  of  which  is  desirable  to  avoid. 

A review  of  the  literature*  has  indicated  that  the  state  of  the 
art  in  the  development  of  analytical  models  of  sophisticated,  highly 
complex  queueing  systems  has  not  advanced  sufficiently  to  be  applied  to 
the  SAR  system,  without  the  drawback  of  making  over-simplifying 
assumptions.  For  example,  the  heterogeneity  of  the  physical  capabilities 
of  the  several  different  resource  types  make  the  analytical  modeling 
approach  essentially  untractable  for  investigating  the  trade-offs  of 
various  resource  type  mixes  for  servicing  a given  caseload.  Some 
additional  complications  are:  Calls  for  service  are 

distributed  over  time  and  geography  according  to  distributions  that 

* See  references  1 through  11 
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are  known  only  empirically;  the  service  process  is  of  priority  interrupt 
type,  and  a client's  priority  may  change  as  a result  of  either  undergoing 
service  or  of  being  interrupted,  or  both;  the  needs  of  the  client  may 
vary  widely  in  both  type  and  amount  --  for  example,  a case  may  be  a simple 
single  resource  tow  lasting  a half  hour  or  a complex  search  case  involving 
several  aircraft,  cutters  and  boats  for  a week  or  more.  Although  queueing 
systems  with  some  of  the  above  characteristics  have  been  examined  in  the 
literature,  the  combination  of  all  of  these  complexities,  and  many  more, 
does  not  appear  to  solvable  analytically.  And  if  a sufficiently 
complex  analytical  model  could  be  developed,  it  would  undoubtedly  consume  a 
considerable  amount  of  time  and  money,  to  the  point  that  its  solution  would 
probably  not  be  timely. 

Simulation,  the  third  approach,  although  also  costly  in  both  design 
time  and  money,  has  the  potential  of  yielding  the  most  flexible  methodology, 
and  could  perhaps  provide  the  best  payoff  to  Coast  Guard  management. 

Simulation  modeling  is  preferred  over  controlled  real-world  SAR 
experimentation  since  it  avoids  the  risks  of  direct  experimentation  with 
the  general  public.  Furthermore,  simulation  offers  considerably  more 
flexibility  than  the  limited  experiments  which  might  be  undertaken 
directly.  Simulation  modeling  is  also  preferred  to  analytic  modeling 
where  the  problem  characteristics  prohibit  timely  solution  with  current 
state  of  the  art.  The  SAR  response  devolves  on  a fairly  complex  set 
of  decisions  within  a hierarchy  of  a formal  organization.  These  decisions 
encompass  the  differing  physical  capabilities  of  the  inventory  of  SAR 
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resources,  the  environmental  conditions  at  the  time  of  the  incident, 
the  service  requirements  of  each  client,  the  server  disciplines,  etc. 
Often  such  complex  problems  can  be  formulated  analytically,  but  cannot 
be  solved  analytically  in  a timely  fashion  for  immediate  use.  Although 
the  analytic  approach  could  work  if  the  complexities  of  the  SAR  system 
could  be  sufficiently  simplified,  such  an  approach  would  almost  certainly 
fall  short  of  adequately  answering  Coast  Guard  management's  questions. 

Frequently,  simulation  is  considered  only  as  a "last  resort"  after 
other  problem  approaches  are  considered  lacking  and  not  applicable. 
Certain  unique  properties  of  the  simulation  approach,  however,  do  make 
it  attractive  to  the  analyst  in  preference  to  other  techniques. 

To  illustrate,  it  may  desirable  to  observe  the  dynamic  behavior 
of  a process,  especially  a man- system- environment  problem:  such  as  SAR, 
and  collect  a variety  of  simulated  data.  Since  the  ratio  of  simulated 
time  while  observing  this  behavior  to  the  actual  time  can  be  very  small, 
a large  assortment  of  experiments  can  be  performed.  Often  simple 
performance  criteria  for  evaluating  a system  just  do  not  exist;  or  the 
observers  of  the  system  may  evaluate  its  performance  quite  differently. 
These  last  two  points  make  simulation  more  attractive  as  the  approach 
to  solving  the  SAR  problem,  as  a single  static  point  solution  leaves 
Coast  Guard  management  without  a spectrum  of  resultant  observations  both, 
aggregate  and  detailed,  for  making  the  best  decision  for  SAR  planning. 

A secondary  value  of  simulating  a system  is  its  use  in  developing 
and  testing  tactical  operating  policies  and  procedures.  Often,  portions 
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of  the  simulation  model,  close  replicas  of  the  real  system,  can  be  used 
as  training  devices  (similar  to  operational  games) , allowing  the  user 
to  change  input  conditions,  make  decisions  during  the  game  and  observe 
the  system  response.  Not  only  can  this  become  an  effective  training 
device,  but  it  also  can  provide  insight  when  the  user  is  interested  in 
certain  dynamic  interactions,  rather  than  the  overall  behavior  of  the 
system. 

There  are  drawbacks  to  simulation  in  that  the  development  and  exercise 
of  such  a complex  model  could  prove  to  be  very  expensive.  However, 
when  it  is  realized  that  a savings  of  only  1 % of  the  $150  million  annual 
budget  for  SAR  could  easily  repay  the  investment  several  times  over, 
the  expense  of  simulation  does  not  seem  so  critical. 

The  question  always  arises  as  to  the  validity  of  a simulation 
model  (or  any  model  or  empirical  examination  of  a problem) . Model 
validation  is  indeed  a topic  in  itself,  and  is  treated  in  a separate 
report,  but  some  thoughts  are  noted  briefly  in  this  section. 

Validation,  too,  can  be  expensive,  and  even  unproductive,  but  there 
are  reasons  to  believe,  before  building  the  simulation,  that  a successful 
validation  for  the  SAR  model  is  possible.  First,  there  exists  a relatively 
good  and  complete  data  base  of  SAR  incidents.  Second,  the  SAR  model  can 
be  constructed  so  that  it  is  essentially  deterministic  in  nature  (as 
opposed  to  probabilistic).  Thus,  the  confidence  that  it  is  a good 
replica  of  the  SAR  system  can  be  gained  from  a few  simulation  exercises 
and  a comparison  of  the  simulation  results  with  some  carefully  prepared 
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statistics  generated  from  historical  data.  In  contrast,  if  the 
simulation  were  highly  probabilistic,  many  exercises  would  be  necessary 
to  gain  assurance  that  the  model  is  an  adequate  replica  of  the 
system. 

In  summary,  the  simulation  approach  has  been  selected  as  the 
methodology  for  studying  the  SAR  problem  because  of  its  several  advantages , 
few  disadvantages  and  high  probability  of  success. 
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3. 


Design  of  the  Simulation 


The  purpose  of  this  section  is  to  review  the  major  design  considera- 
tions which  were  analyzed  during  the  design  phase  of  the  Search  And 
Rescue  Simulation  (SARSIM)  model.  It  is  felt  that  this  section  will  be 
helpful  towards  obtaining  a fuller  understanding  of  the  descriptions  of 
the  algorithms  of  SARSIM  presented  in  Part  II  of  this  volume. 

Inputs  and  Outputs 

A simple  yet  effective  way  of  viewing  the  overall  SARSIM  model 
is  via  its  inputs  and  outputs.  The  inputs  to  the  model  are  in  part 
dictated  and  constrained  by  the  available  SAR  data  base.  The  core 
of  the  data  base  is  the  set  of  SAR  Assistance  Reports  which  are  filled 
out  for  each  distress  case  the  Coast  Guard  answers.  Figure  1 shows  a 
sample  report  and  indicates  the  kind  of  information  that  is  available. 

In  retrospect,  almost  every  item  on  this  form  is  used  in  SARSIM  either 
directly,  via  parameters  calculated  from  these  items;  for  post-processing 
analysis  (e.g.  "Value  of  Property  Involved");  or  for  validation  compari- 
sons. Further,  much  of  this  data  was  used  during  the  design  process 
to  verify  many  of  the  model's  assumptions. 

Three  years  of  this  data  (approximately  40,000  cases  per  year) 
were  cleaned,  organized,  sorted,  and  merged  at  the  National  Bureau 
of  Standards  just  prior  to  and  during  the  early  stages  of  the  simulation 
development.  Although  many  automatic  checks  were  made  during  the 
cleaning  of  this  data,  some  key  punch  errors  and  inconsistencies  may 
still  exist,  not  to  mention  the  possibility  that  the  information  may 
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SAMPLE  ASSISTANCE  REPORT 
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SAMPLE  .ASSISTANCE  REPORT  (continued) 
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have  been  erroneously  recorded  at  the  origin  Despite  these  facts, 
this  data  base  represents  a valuable  resource  for  the  design,  operation 
and  validation  of  the  model. 

The  exogenous  inputs,  then,  for  SARSIM  are  the  historical  cases 
and  their  attributes,  for  example:  date  and  time  of  notification, 

location,  environmental  conditions,  assistance  rendered  (need),  case 
severity,  search  requirements,  etc. 

The  endogenous  inputs  are  used  to  describe  the  SAR  system  to  be 
simulated.  These  user  inputs  include:  district  identification; 

station  data  (including,  for  each  station:  location,  number  and  types 
of  resources , covering  aircraft  stations  and  cutters , crew  manning 
levels  for  each  shift,  etc.);  resource  type  data  (including  for  each 
resource  type:  operating  costs,  endurance,  speeds  capabilities 

reliability,  etc.);  shift  data;  tolerance  times  as  a function  of 
severity  levels  and  case  type;  standby  data;  and  many  more  descriptors 
of  the  system  to  be  simulated. 

The  outputs  for  a given  run,  or  exercise,  of  the  model  can  be 
categorized  into  two  basic  types.  First  are  case  outputs , which  include 
such  summary  statistics  on  the  cases  serviced  during  the  simulation 
exercise  as:  average  waiting  time;  average  service  time;  number  of 

incidents  of  interrupts  and  queueing;  etc.  The  second  type 
are  the  system  outputs , which  measure  such  things  as  the  utilization  of 
resources  (overall,  by  station,  by  resource  type,  by  time  period  etc.); 
number  of  system  failures;  number  of  standby  call-ups,  etc. 
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The  outputs  described  above  are  all  automatically  printed  after 
every  run  of  the  model.  Additional  information  can  also  be  obtained 
concerning  case  outputs  via  a postprocessor  program.  If  the  user  chooses 
to  have  this  additional  output,  he  can  specify  that  an  output  case 
tape  be  created;  then  the  postprocessor  can  use  this  tape  to  retrieve, 
analyze  and  print  out  the  additional  statistics  desired  by  the  user. 
Boundaries 

The  choice  of  the  district  as  the  basic  boundary  of  the  model 
has  already  been  discussed.  (See,  in  Section  1,  the  discussion  under 
"Scope.") 

Methodology  for  Treating  Time  Advance 

An  investigation  of  the  SAR  data  base  revealed  that,  even  during  the 
peak  boating  season,  on  the  average  only  about  3 to  51  of  the  SAR  resources 
are  busy  at  any  particular  time.  In  other  words,  there  is  very  little 
"interesting"  (i.e.,  SAR)  activity  during  most  of  the  time.  On  the  other 
hand,  when  cases  do  come  up,  the  amount  of  activity  is  very  high  and  the 
average  time  between  significant  events  becomes  small.  For  these  reasons 
it  was  decided  that  the  time  advance  mechanism  in  the  model  should  be 
discrete,  rather  than  continuous,  and  event  oriented  rather  than  time 
interval  oriented.  This  approach  is  highly  efficient  for  SARSIM,  since  the 
computer  need  do  no  work  during  the  long  periods  of  inactivity;  yet  during 
periods  of  high  activity,  the  computer  will  be  able  to  simulate  all  of  the 
interesting  events  regardless  of  how  fast  they  occur.  SARSIM  then  has 
been  modeled  as  a discrete  event  digital  simulation. 
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Level  of  Detail 


Any  simulation  is  limited  in  the  number  of  events  it  can  handle 
efficiently.  The  district  caseload  (approximately  7000  per  year) 
is  sufficiently  small  that  multiple  events  for  each  case  can  be 
considered.  Therefore,  for  each  case,  in  addition  to  origination 
and  termination,  it  will  be  possible  to  simulate  other  events  such 
as  notification,  response /launch,  on  scene,  interrupt (s) , priority 
change(s),  and  searching,  etc.  in  order  to  make  the  model  more  realistic 
These  added  events  will,  for  example,  allow  a resource  enroute  to  a 
case  to  be  diverted  to  another  case  of  higher  priority  (i.e.,  interrupt) 
It  will  also  allow  a case  in  progress  to  have  its  priority  change  (in 
either  direction)  to  reflect  changing  conditions  and  assistance 
already  received. 

Since  the  Coast  Guard  desired  to  investigate  alternative 
resource  mixes,  it  was  not  sufficient  that  the  simulation  merely 
assign  the  same  resource  type  to  a given  case  as  was  assigned 
historically.  Therefore,  a highly  sophisticated  set  of  resource  assign- 
ment algorithms  had  to  be  designed  such  that  the  preferred  resource 
(or  resources,  for  a multi-resource  case)  is  selected  from  all  the 
existing  resources  being  simulated  for  assignment  to  each  case.  The 
provision  for  priority  interrupt,  of  course,  further  complicates  these 
algorithms. 

The  resource  assignment  algorithm  for  long*  search  cases  is 


*Cases  involving  searches  of  less  than  one-half  hour  duration  are 
handled  separately. 
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somewhat  more  complex  than  for  non-search  cases  because  of  the  widely 
differing  capabilities  for  search  among  the  various  resource  types. 
However,  the  servicing  of  a search  case  in  the  model  is  less  detailed 
than  the  servicing  of  a non- search  case.  This  is  due  to  the  limited 
data  available  in  the  data  base  on  how  the  search  was  carried  out  (e.g., 
search  pattern,  track  width,  etc.  are  not  given)  and  also  due  to  the 
relatively  minor  incidence  of  long  search  cases  in  the  overall  SAR 
system.  Only  a small  fraction  of  the  total  SAR  caseload  involves 
a long  search  requirement.  However,  when  such  a case  does  come  up,  it 
consumes  a considerable  amount  of  (usually  expensive)  resource  time. 
Therefore,  the  objective  of  servicing  long  search  cases  in  the  simulation 
was  mainly  to  account  for  this  resource  utilization  when  the  relatively 
unlikely  event  of  a long  search  comes  up  --  because  the  resources 
occupied  on  a search  case  will  not  be  available  (unless  interrupted) 
for  the  more  common  non-search  cases.  Hence  the  level  of  detail  need 
not  be  as  fine  for  these  long  search  cases. 

Selection  of  Programming  Language 

As  a result  of  a comprehensive  analysis  of  the  available  programming 
languages  and  associated  computer  systems,  the  SIMSCRIPT  1.5  language 
was  chosen  for  basic  operational  module  of  SARSIM.  A report  entitled: 
"Selection  of  Programming  Language,"  Feb.  20,  1970,  was  delivered  to 
the  Coast  Guard  which  presented  this  analysis  and  recommended  this 
language. 

FORTRAN  V is  used  for  the  preprocessing  programs  because  of  its 
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universality  and  suitability  to  these  kinds  of  calculations. 

QUICK  QUERY  is  used  for  postprocessing  because  it  is  compatible  with 
the  SIMSCRIPT  language. 

Methodology  for  Case  Generation 

The  generation  of  the  demand  tape  containing  the  exogenous 
case  inputs  is  based  on  the  SAR  data  base  and,  in  particular,  each 
generated  case  is  obtained  from  the  description  of  an  actual  case  which 
has  occurred  historically.  A discussion  report  of  the  advantages  and 
drawbacks  of  this  data  base  approach,  as  compared  to  a highly 
conditional  Monte  Carlo  approach  where  each  attribute  of  each  case 
is  obtained  from  conditional  distributions,  has  been  submitted*  to 
the  Coast  Guard.  These  advantages  are  summarized  here: 

a.  Using  actual  historical  cases  and  their  attributes 
precludes  the  possible  generation  of  cases  whose 
attributes  are  not  entirely  consistent  within  the  case. 

b.  The  conceptualization  and  development  of  a highly  conditional 
Monte  Carlo  preprocessor  that  is  both  consistent  and  accurate 
would  be  highly  time  consuming.  Much  data  analysis  would  be 
required  to  determine  a feasible  trade-off  among  the  accuracy 
in  generating  cases,  a manageable  program,  and  the  computer 
storage  limitations. 

c.  Using  historical  cases  and  their  attributes  contributes 
to  the  task  of  validation.  It  is  much  more  meaningful  to 


*Karp,  S.S. , "Alternatives  for  Geographically  Locating  SAR  Cases," 
5/11/70 
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Structure  of  SARSIM 


For  any  programming  system  of  the  size  and  complexity  of  SARSIM, 
there  exists  a strong  motivation  to  construct  it  in  a highly  modular 
fashion.  The  reasons  for  this  are  due  to:  (1)  the  economics  of 
operating  the  model  modular ly;  (2)  the  greater  efficiency  and  simplicity 
of  programming  small,  discrete  modules;  and  (3)  the  advantage  that  the 
different  functional  parts  can  be  written  in  different  languages,  each 
appropriate  for  its  module. 

A very  natural  organization  for  SARSIM  was  to  divide  the  overall 
model  into  three  major  functional  blocks:  the  Preprocessor  (PREPRO) , 

the  Operational  Simulator  (OPSIM) , and  the  Postprocessor  (POSTPRO) . 

The  Preprocessor  is  a set  of  FORTRAN  programs  which  prepares  the 
exogenous  demand  tape  from  the  historical  SAR  data  files.  This  demand 
tape  contains  a chronological  ordering  of  cases  with  their  respective 
attributes.  The  user  can  vary  the  caseload  either  overall  or  by 
selected  criteria,  such  as  specific  case  parameters,  to  produce  any 
desired  forecast  demand  scenario.  The  Operational  Simulator  is  the 
basic  module  of  SARSIM.  It  is  a discrete  event  digital  simulation 
written  in  SIMSCRIPT  which  models  the  assignment  of  the  preferred 
resource (s)  and  simulates  the  service  of  each  case.  It  calculates 
certain  summary  statistics  for  standard  output  and  can  produce  an  output 
case  tape  for  further  detailed  analysis  by  the  Postprocessor.  The 
QUICK  QUERY*  information  retrieval  system  is  used  to  provide  this  analysis. 

*Developed  for  the  Economic  Development  Administration  by  Consolidated 
Analysis  Centers  Incorporated,  Santa  Monica,  California,  U.S.A. 
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The  economics  of  this  approach  are  readily  apparent.  The 
costly  and  time-consuming  task  of  preparing  an  exogenous  demand 
tape  can  be  done  off-line  in  the  Preprocessor.  Once  a satisfactory 
tape  has  been  generated,  it  can  be  used  numerous  times  by  the 
Operational  Simulator  to  compare  the  performance  of  alternative 
system  configurations  (e.g. t different  resource  levels,  mixes, 
locations,  etc.)  when  using  the  same  caseload  scenario.  The 
most  promising  of  these  runs  can  then  be  investigated  in  more 
detail  via  runs  of  the  Postprocessor.  This  approach  then  can 
eliminate  much  unnecessary  repetitive  processing. 

A further  advantage  in  the  case  of  SARSIM  is  that  nearly 
all  of  the  stochastic  elements  of  the  simulation  can  be  resident 
in  PREPRO,  leaving  OPSIM  relatively  deterministic.  In  this  way, 
several  runs  of  PREPRO  can  be  made  creating  several  different  scenario 
tapes,  because  each  is  started  using  a different  random  number 
seed.  (The  program  currently  allows  for  ten  different  scenarios 
to  be  generated  during  a single  execution  of  PREPRO.)  Summary 
statistics  are  also  output  on  each  scenario  allowing  the  user  to 
select  an  appropriate  demand  tape  from  those  created.  The  selected 
tape  can  then  be  input  to  OPSIM,  which  services  these  cases  nearly 
deterministically.  (The  only  randomness  in  OPSIM  is  in  the  probability 
of  an  on-line  failure  of  the  selected  resource,  and  the  probabilistic 
reevaluation  of  the  case's  severity  during  its  service.)  This  not 
only  makes  OPSIM  very  efficient  in  its  processing  of  the  caseload,  but 
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also  fewer  repetitions  of  OPSIM  runs  are  now  required  because  of 
the  small  variance  in  OPSIM  outputs  due  to  these  minor  stochastic 
effects.  Similarly,  as  mentioned  previously,  a relatively  deter- 
ministic OPSIM  is  far  easier  to  validate  than  a stochastic  representa- 
tion. 

Each  of  the  three  functional  blocks  of  SARSIM  is  further 
functionally  modularized.  The  PREPRO  organization  is  very  straight- 
forward; its  five  basic  parts  are:  (1)  a set  of  "cleaning  routines" 

to  edit  and  correct  errors  in  the  data  base;  (2)  a set  of  data 
processing  programs  to  sort  and  organize  the  data  base  such  that  it 
is  compatible  with  the  requirements  of  OPSIM;  (3)  a program  for 
calculating  additional  case  parameters  required  by  the  OPSIM 
program;  (4)  a program  for  randomly  generating  caseloads;  and  (5) 
a program  for  generating  caseloads  in  their  historic,  chronological 
order  (for  validation  purposes) . 

The  organization  of  OPSIM  is  based  primarily  on  a partitioning  of 
the  types  of  SAR  cases  encountered  in  actual  practice.  Although  this 
partitioning  can  be  done  in  several  ways,  a very  natural  and  manageable 
categorization  became  apparent  in  terms  of  the  multiplicity  of  resources 
responding  to  a case.  An  examination  of  the  SAR  data  base  revealed 
that  about  85%  of  all  cases  are  serviced  by  a single  Coast  Guard 
resource,  while  the  remainder  required  two  or  more  resources.  Further, 
the  simulation  of  the  selection  process  for  assigning  the  preferred 
resource (s)  to  a case  is  conceptually  very  different  from  the  simulation 
of  the  servicing  of  a case.  For  these  reasons,  it  was  advantageous  to 
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construct  the  Single  Resource  Assignment  Subroutine  (SRAS)  as 
the  basic  module  of  OPSIM. 

Cases  requiring  a multiplicity  of  resources  are  handled  by 
the  Multi  Resource  Assignment  Subroutine  (MRAS) . MRAS  relies 
heavily  on  part  of  SRAS  in  assigning  the  individual  participants 
to  a multi-resource  case.  In  addition,  MRAS  performs  the  scheduling 
of  the  several  resources  on  a given  case,  provides  for  continuous 
coverage  of  the  distress  client,  and  simulates  the  coordination 
necessary  for  such  events  as  multiple  (hand- off)  tows  and  interrupt 
of  a resource  involved  in  a multi -resource  case. 

Simulation  of  the  service  of  both  single  and  multi -resource 
cases  is  performed  by  the  Service  Subroutine  (SS) . In  addition 
to  scheduling  all  the  service  functions  that  must  be  performed, 

SS  also  calculates  the  statistics  that  are  output  at  the  conclusion 
of  the  OPSIM  run. 

Because  both  the  assignment  rules  and  the  servicing  of  long 
search  cases  are  very  different  than  for  non- search  cases  (as 
was  discussed  previously) , a separate  module  for  simulating  long 
search  cases  was  constructed.  The  Search  Assignment  and  Service 
Subroutine  (SASS) , as  the  name  implies,  simulates  both  the 
assignment  of  resources  to  search  cases  as  well  as  the  service 
of  this  portion  of  a case.  If  at  the  conclusion  of  a search  the 
client  requires  additional  service,  either  SRAS  or  MRAS,  as 
appropriate,  is  called  by  the  OPSIM  Executive  Routine  (OPSIM  EXEC) 
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to  complete  the  case. 

OPSIM  EXEC  performs  similar  control  functions  on  other  types 
of  cases  as  well  as  managing  such  interface  functions  as  maintaining 
queue  discipline  and  interrupt  control.  It  also  handles  such 
"bookkeeping"  functions  as  terminating  the  simulation  of  cases  at  the 
appropriate  time  and  calling  the  statistics  and  output  programs  within 
OPSIM. 

The  Postprocessor  is  composed  of  two  functional  parts.  The 
File  Definition  and  Maintenance  (FDM)  software  is  used  to  actively 
create  (define)  the  file  of  output  cases  from  OPSIM,  or  to  modify 
an  existing  file,  so  that  it  is  compatible  with  the  requirements 
of  the  QUICK  QUERY  language.  The  Quick  Query  Program  (QOP)  is  used 
used  to  passively  access  this  file  for  data  retrieval,  manipulation 
and  display.  Generally  FDM  is  run  only  once  for  a given  output 
from  OPSIM,  while  QQP  may  be  run  several  times  to  obtain  different 
analyses  and  statistical  printouts.  This  is  another,  although  minor, 
example  of  how  the  economies  of  operating  the  model  modularly  are 
achieved  via  the  SARSIM  structure. 

Model  Assumptions 

As  a result  of  much  analysis  of  the  SAR  data  base,  and  discussions 
with  many  Coast  Guard  officers  having  operational  SAR  experience, 
together  with  the  necessity  of  making  simplifications  because  of 
constraints  on  computer  storage,  execution  time,  etc.,  several 
simplifying  assumptions  were  made.  The  most  major  of  these  were 
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presented  earlier  under  the  Section  "Scope."  The  more  important 
of  the  remainder  are  given  below. 

1.  Primary  Station  Assignment 

In  the  actual  SAR  system  the  assignment  of  a case  to  a shore 
station  is  generally  made  on  the  basis  of  the  stations’  geographical 
"area  of  responsibilities."  Because  of  the  difficulty  of  treating  this 
in  the  model  (due  to  complex,  sometimes  concave  areas) , and  because 
these  areas  would  have  to  be  redefined  everytime  a station  was  added, 
deleted,  or  its  location  changed,  a simpler  approach  was  taken.  This 
approach  is  that  the  station  closes  to  the  location  of  the  case,  from 
among  the  station  which  handled  the  case  historically  and  its  adjacent 
stations,  is  assigned  as  the  primary  station.  Note  that  the  historical 
primary  station  does  not  necessarily  serve  the  case  in  the  model;  this 
is  described  more  fully  in  Part  II,  Section  3A  (SRAS). 

2.  Sequence  of  Events 

The  macroscopic  sequence  of  events  in  SARSIM  has  been  fixed  in 
order  to  prevent  unnecessary  complications.  Thus,  if  any  long  search 
requirement  exists,  it  must  be  performed  first.  If  the  client  is  found 
and  requires  further  on-scene  assistance,  this  is  done  next.  Finally, 
if  a tow  or  escort  is  needed,  this  will  be  simulated  to  conclude  the 
case.  It  has  been  determined  that  very  few  exceptions  to  this  sequencing 
have  occurred  in  actual  practice. 

3.  A Priori  Search  Requirement 

Consistent  with  the  objectives  of  the  search  routine,  discussed 
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earlier  under  "Level  of  Detail,"  the  search  requirement,  in  terms  of 
total  search  miles,  is  known  for  a case  before  the  search  begins.  The 
number  of  search  miles  to  be  searched  in  SARSIM  is  set  equal  to  the 
amount  searched  for  this  case  historically.  Again,  search  is  a back- 
ground activity  simulated  to  account  for  expended  resource  time. 

No  attempt  is  made  to  optimize  search  procedures . 

4.  On-Scene  Needs 

The  type  of  service  a case  requires  has  been  defined  in  SARSIM 
as  the  need(s)  of  the  case.  Examples  of  on-scene  needs  (i.e.,  other 
than  search  or  tow)  are  firefighting,  dewatering,  provide  equipment, 
refloating,  evacuate  personnel,  etc.  The  needs  of  a historical  case 
are  determined  indirectly  from  its  SAR  Assistance  Report  from  the 
three  "Assistance  Rendered"  items  (Figure  1).  Since  one  need  per 
resource  is  required  by  the  model  (See  ' 'Multi-Resource  Cases" 
assumption,  below)  a dominance  pattern  had  to  be  created  so  that  the 
most  important  need  per  resource  would  be  used.  A description  of 
how  this  is  done  is  given  in  Part  II,  Section  2 (PREPRO) . 

5.  Equi- Capability 

Given  the  need  of  a case,  its  location  and  the  environmental 
conditions,  a subset  of  the  district’s  resources  are  checked  in  the  model 
to  determine  whether  each  is  capable  of  serving  the  case.  In  so  doing, 
the  assumption  of  equi -capability  is  made  with  respect  to  the  resource 
selection  process.  For  example,  if  two  different  resources  are  both 
capable  of  serving  the  need  of  the  case,  under  the  given  environmental 
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conditions,  regardless  of  the  fact  that  the  performance  by  one  may 
be  superior  to  the  other,  each  is  considered  as  fully  capable,  for 
purposes  of  resource  selection.  (Other  factors,  such  as  time  of 
response,  cost,  busy- idle  status,  home  station,  etc.  are  also 
considered  in  the  selection  process  for  the  set  of  capable  resources.) 

In  other  words,  capability  in  SARSIM  is  a binary  decision. 

6.  Tolerance  Concept 

Basic  to  the  resource  selection  algorithm  is  the  concept  that  a 
distress  client  should  be  served  within  a given  tolerance  time  which 
varies  with  (five  levels  of)  his  distress  severity.  All  resources 
which  are  capable  of  serving  the  need  of  the  client,  under  the  existing 
environmental  conditions,  witin  the  tolerance  time  are  considered 
equally  satisfactory  from  a performance  point  of  view.  That  is,  a 
resource  which  could  arrive  earlier  than  the  tolerance  time  is  not  given 
preference  over  one  which  would  arrive  later,  but  still  within  tolerance. 
(A  ranking  based  on  cost  is  made  to  select  the  preferred  resource 
among  those  which  can  meet  tolerance.)  Only  in  the  situation  that  no 
resources  can  meet  the  tolerance  time,  will  preference  be  given  to  the 
faster  resource. 

7.  Weather  Conditions 

Since  actual  historical  cases  are  used  in  the  generation  of  cases 
(see  ' Methodology  for  Generating  Cases") , all  weather  descriptors  for 
a given  case  are  consistent.  This  avoids,  for  example,  the  possibility 
of  having  a case  with  50  knot  winds  and  calm  sea  state.  However,  using 
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the  option  of  random  generation  of  cases,  it  is  possible  to  have 
several  simultaneous  cases  in  the  simulation  system,  but  with  different 
weather  conditions.  This  was  considered  acceptable  by  the  Coast  Guard 
because  it  was  felt  that  it  was  preferable  to  have  internal  consistency 
within  a case,  rather  than  consistency  across  cases.  To  provide  both 
appeared  to  be  a major  effort,  but  one  which  would  not  produce 
significantly  better  results. 

8.  Multi- Resource  Cases 

Since  SARSIM  is  basically  a model  which  accounts  for  the  utilization 
of  resources,  it  is  important  that  the  simulation  be  able  to  replicate 
this  utilization  fairly  closely.  In  the  case  of  multi -resource 
responses  to  cases,  it  is  difficult  to  determine  from  the  cases’ 

Assistance  Reports  why  the  given  number  of  resources  were  used  on 
a given  case.  That  is,  there  exist  many  cases  in  the  data  base  which 
appear  to  be  very  similar,  yet  a different  number  of  resources  were 
used  on  each  case. 

The  basic  assumption  used  for  these  multi- resource  cases  is  that  the 
simulation  will  respond  to  the  same  number  of  needs  that  were  responded  to 
historically.  Although  this  approach  has  the  disadvantage  of  limiting 

the  investigation  of  alternative  numbers  of  resources  in  serving  these 
cases,  it  has  the  advantages  of  both  simplicity  of  modeling  as  well  as 

accuracy  in  replicating  history.  It  should  also  be  noted  that  only 
about  15%  of  all  non- search  SAR  cases  are  multi -resource,  therefore 

the  effect  of  this  assumption  is  not  dominant. 
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9.  Output  Measures 

Although  most  of  the  outputs  are  derived  straightforwardly,  some 
have  inherent  assumptions  which  need  explanation  for  proper  interpre- 
tation. 

a.  Exceptional  Cases 

These  are  cases  which  possess  such  unusual  combinations  of 
attributes  that  they  cannot  be  served  within  OPSIM. 

This  condition  is  usually  due  to  an  erroneous  data  item  in 
the  Assistance  Report;  it  may  also  be  due  a resource  which 
exceeded  its  rated  capability  historically  to  serve  a case 
in  distress.  Also,  certain  air  escort  cases  can  become 
"exceptional  cases"  if  unusual  combinations  of  queueing 
and  interrupt  occur.  This  was  accepted  to  avoid  modeling  a 
very  complex  situation  which  occurs  for  less  than  one 
percent  of  the  caseload. * 

b.  Utilization  Statistics 

Utilization  indices  (in  %)  are  calculated  on  the  basis  of 
the  total  number  of  resources  of  a given  category,  rather 
than  on  the  number  of  "ready"  resources.  For  example,  a station 
having  five  boats  of  different  types  and  two  crews  (i.e.,  two 
ready  boats)  which  expended  72  hours  of  resource  time  on  SAR  cases 
during  a month,  will  have  a utilization  of  2.0%  (based  on  the 
five  boats)  rather  than  a utilization  of  5.0%  (based  on  the  two 
crews).  This  method  was  used  because  it  would  not  be  possible 

^However,  a read-out  is  provided  automatically  to  describe  any  such 
exceptional  cases . 
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to  obtain  utilizations  of  resource  types  if  crew  utilization 
were  used,  since  crews  may  serve  on  several  different  resource 
types.  It  is  also  important  to  note  that  this  index  is  not 
used  here  as  a measure  of  system  performance,  but  rather  as 
a check  on  the  model's  validity.  Therefore,  as  long  as  the 
comparative  historical  utilizations  are  calculated  in  the 
same  way,  there  should  be  no  misunderstanding, 
c.  Waiting  Time 

The  assumption  inherent  in  the  calculation  of  waiting  time  of 
a case  is  that  is  based  on  the  first  arrival  of  a resource  to  the 
scene  of  the  incident.  It  is  therefore  this  arrival  time  minus  the 
case's  notification  time.  Subsequent  waiting,  either  due  to  delays  of 
other  resources  (for  a multi -resource  case)  or  due  to  interrupt  of  the 
first  resource  after  it  has  arrived  on  scene,  is  not  included  in  the 
calculations.  This  is  based  on  the  notion  that  a client's  anxiety  will 
have  been  satisfied  once  the  first  resource  arrives  to  assist  him;  also, 
the  first  resource  is  likely  to  overcome  quickly  the  critical  part  of  the 
incident  in  its  first  few  minutes  on  scene.  The  remainder  of  the  case 
is  usually  of  a more  routine  nature.  The  output  measures  "C  Failures" 
(cases  waiting  longer  than  their  tolerance  times)  and  "Demerit"  (a 
measure  of  excess  waiting  time)  are  also  based  on  this  same  concept 
of  waiting. 
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Part  II.  Details  of  the  Simulation 


1.  Introduction  to  Part  II 

The  Search  and  Rescue  Simulation  Model  (SARSIM)  is  an  event -oriented 
computer  program  based  on  Coast  Guard  search  and  rescue  activities, 
as  discussed  in  Part  I of  this  volume.  It  is  comprised  of  three 
major  program  packages  which  may  be  employed  flexibly  to  explore 
particular  sets  of  input  conditions.  The  remainder  of  this  volume  is 
devoted  to  comprehensive  presentations  for  these  major  functional 
blocks  of  SARSIM:  the  PREPROCESSOR  (PREPRO) , the  OPERATIONAL  SIMULATOR 

(OPSIM) , and  the  POSTPROCESSOR  (POSTPRO) . Particular  emphasis  will  be 
placed  on  modeling  the  complex  SAR  system  in  OPSIM. 

The  simulation  is  designed  to  be  exercised  for  a district,  as 
defined  by  the  Coast  Guard.  Selection  of  the  district  level  was 
prompted  by  constraints  imposed  by  limitations  of  computer  storage, 
plus  the  fact  that  there  is  generally  negligible  interaction  between 
districts  except  for  the  employment  of  long-range  resources , such  as 
the  C-130.  The  limited  number  of  these  special  resources,  which  are 
made  available  to  any  district  on  a given  coast,  are  easily  included 
in  the  resource  profile  and  are  exercised  in  the  simulation  for  those 
cases  requiring  them. 

The  discussion  of  PREPRO  explains  the  procedures  and  programs 
entailed  in  generating  an  exogenous  Demand  Tape;  the  programs  are 
currently  designed  for  use  with  the  pre-Fiscal  Year  1970  data  format 
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of  the  SAR  Assistance  Reports  prepared  by  the  Coast  Guard  for  each  case 
encountered.*  The  Demand  Tape  is  then  processed  through  OPSIM,  where 
service  for  the  case  is  simulated  and  summary  statistics  are  collected 
and  printed  as  standard  output. 

Finally,  a prepackaged  information  retrieval  system  can  be  used  in 
POSTPRO.  A great  deal  of  pertinent  information  is  offered  as  standard 
output  in  the  summary  statistics  provided  by  OPSIM,  including  utilization 
statistics  for  each  type  of  resource  and  each  stations,  some  "failure”  data, 
and  an  exceptional  case  file  (that  is , cases  which  cannot  be  served) . These 
data  are  highly  aggregated,  however,  and  may  tend  to  mask  out  significant 
items  of  interest.  The  prepackaged  concept  for  POSTPRO  is  an  exceptionally 
attractive  approach  in  that  it  provides  a mechanism  for  filtering  out  special 
summary  information  on  selected  types  of  cases  of  particular  interest  to  the 
user. 

An  overview  of  the  structure  of  SARSIM  is  shown  in  the  three  related 
sections  of  Figure  2.  Individual  cases,  with  their  description  attributes, 
are  prepared  and  ordered  in  PREPRO.  Resources  are  assigned  to  provide 
services  for  these  cases  in  OPSIM,  which  also  generates  output  data  with 
regard  to  cases  and  resources.  More  detailed  analysis  of  the  processed 
cases  can  be  conducted  in  POSTPRO  to  satisfy  requests  for  special 
information. 

2.  PREPRO  - The  Preprocessor  for  SARSIM 

The  fundamental  purpose  of  PREPRO,  the  Preprocessor,  is  to  prepare 

*Treasury  Department,  U.  S.  Coast  Guard,  CG-3272  (revised  9-65) 
Assistance  Report. 
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an  exogenous  DEMAND  TAPE,  which  is  used  to  drive  OPSIM.  This  DEMAND 
TAPE  contains  sufficient  information  about  historically -derived  case 
parameters  to  pass  control  to  appropriate  subroutines  within  OPSIM. 

Conceptually,  PREPRO  may  be  separated  into  three  major  components: 
a report-editing  routine,  one  for  calculating  case  parameters  for  use 
in  a scenario,  and  a third  for  generating  an  ordered  caseload.  (A 
fourth  routine,  the  Case  Assembly  Processor,  is  also  required  to 
sort  and  collect  similar  cases  requiring  the  services  of  two  or 
more  resources.) 

Figure  (3)  shows  the  major  subroutines  and  ordering  of  steps 
within  PREPRO.  These  are  described  in  detail  in  the  following  sections 

A.  Cleaning  Routines 

A tape  is  prepared  from  historical  SAR  Assistance  Reports, 
organized  by  the  Operating  Facilities  (OPFAC’s)  within  a given  district 
This  tape  is  edited  so  that  obvious  errors  are  removed  and  there  is 
internal  consistency  of  the  data.  The  Cleaning  Routine  results  in 
an  OPFAC  FILE*.  Those  cases  which  required  the  services  of  two  or 
more  units  are  sorted  and  collected  on  their  multi -unit  case  number 
to  produce  the  CASE  FILE,  which  then  becomes  the  input  to  the  Program 
for  Calculating  case  Parameters  (PCP)  of  PREPRO. 

In  addition  to  those  cases  occurring  within  the  district  and 

*The  term  "FILE"  is  used  in  the  sense  of  an  unordered  collection 
of  case  records.  "TAPE”  indicates  a chronological  ordering  of 
case  records. 
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Note:  TAPE  implies  chronological  order;  FILE  does  not. 

Figure  3 

Major  Steps  in  PREPRO 
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filed  on  the  CASH  FILE,  special  attention  is  given  to  those  cases 
served  by  the  long-range  C-130  aircraft,  both  within  and  outside 
the  district  being  exercised.  These  cases,  filed  on  the  C-130 

TAPE,  are  input  to  the  PCP  for  a detemination  of  their  case 

ULfll  fjk  - 

parameters.  The  C-130  TAPE  is  prepared  from  the  caseload  at  the 
air  station  from  which  the  C-130's  are  deployed.  For  example, 
the  cases  at  Elizabeth  City,  N.C.  which  were  historically  served 
by  a C-130  are  culled  and  written  on  the  C-130  TAPE  for  the  east 
coast  of  the  Continental  United  States. 

B.  User  Controls  in  PREPRO 

The  3AR  Assistance  Reports,  as  edited  within  the  cleaning 
routine,  are  the  basic  input  to  PREPRO,  but  subject  to  controls  supplied 
at  the  user's  option.  These  options  include  specification  of  growth 
rates  in  demand  for  services  at  particular  stations  or  for  specified 
classes  of  clients,  as  well  as  the  scenario  description  in  terms  of 
maximum  number  of  cases  to  be  generated  or  calendar  data  limits.  For 
example,  separate  DEMAND  TAPES  can  be  generated  for  such  scenario 
descriptors  as  peak  season  and  non-peak  season. 

C.  Program  for  Calculating  Case  Parameters  (PCP) 

Using  information  from  the  CASE  FILE,  the  PCP  calculates  parameters 
required  in  OPSIM  for  each  case,  whether  or  not  directly  available 
in  the  historical  case  records.  The  data  base  may  be  for  a single 
district  for  a single  fiscal  year  or  for  three  years,  but  all  data 
must  be  consistent  in  format.  (A  developed  program  permits 
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conversion  of  data  from  the  JioldH  (pr©»-1970  format  to  the  one  currently 
in  use,  but  not  conversely.) 

Some  of  the  data  for  the  simulation  ca n be  taken  directly  from 
the  Assistance  Report,  while  other  data  bad  to  be  devised  using 
straightforward  algorithms.  Below  is  a list  of  case  attributes 
developed  in  PGP  which  are  the  input  to  DEMGEN.  Some  of  these 
parameters  correspond  directly  to  the  pre-FY'197Q  SAR  data  format  as 
described  in  USCG  CQdDT  INST  3123. 9A  dated  31  March  1966.  (Note 
that  this  Preprocessor  is  designed  fgsr  the  pre-FY70  data  format 
and  that  modifications  must  be  made  for  any  other  format.) 
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Case  Attributes  Developed  in  PCP 


1. 

AIA: 

District  in  which  the  case  occurred 

2. 

STAND: 

Station  number 

3. 

A3: 

Case  number 

4. 

A4: 

Month  and  year  the  station  was  notified* 

5. 

MINCI : 

Date  and  time  the  station  was  notified* 

6. 

B3: 

Number  of  people  on  board 

7. 

B5: 

Value  of  the  vessel 

8. 

B6: 

Air  temperature 

9. 

B8: 

Wind  force 

10. 

B9 : 

Sea  height 

11. 

BIO: 

Visibility 

12. 

B12A: 

Type  of  distressed  vessel 

13. 

L: 

Length  of  Vessel 

14. 

S: 

Severity  i.e.,  relative  seriousness/urgency 

15. 

n: 

Number  of  needs  other  than  search  or  tow 

16. 

m: 

Number  of  resources  that  towed  or  escorted 

17. 

NN: 

Total  number  of  explicit  needs: 

If  n = 0 and  m > 0,  then  NN  = 1 

If  n > 0 and  m > 0,  then  NN  = n + 1 

If  n = 0 and  m = 0 , then  NN  = 0 


*These  values  are  combined  into  OCCUR,  the  date  and  time  of 
notification. 
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18.  2T: 


19. 


20.  S, 


21.  S 


V 


The  degree  of  non-parallel  service  on  a 
multi -re source  case.  The  range  is  0 - 1, 

where  if  - 1 is  the  series  service  of  the 
case.  See  Section  3B  (MRAS)  for  further 
explanation. 

Length  of  time  spent  on  scene  serving  a multi - 
resource  case.  If  t =0,  then  the  case  is  one 
of  the  following:  (a)  search;  (b)  tow;  (c)  escort; 

(d)  search  and  tow;  or  (e)  search  and  escort. 
Equivalent  number  of  resources  operating  in  parallel 
on  a long  duration  search  case.  If  S^  = 0,  then 
the  case  does  not  involve  a long  search  prior  to 
serving  any  other  needs. 

Indicates  if  a short  search  is  required  before 
serving  the  first  need. 

r0,  if  there  is  no  short  search 

1,  if  the  resource  serving  the  first  need 
also  searches  for  the  client 

2,  if  an  additional  resource  is  called  to 
search  for  the  client 

If  TSM 


22. 

TSM: 

The  Total  number  of  Search  Miles  on 

a case. 

= 0,  then  both  S^  = 0 and  o. 

23. 

MILES: 

The  distance  off  shore 

24. 

X 

Case  location  in  nautical  miles  relative  to  a 

user  input  district  origin.  If  the 

location 

j: 

unknown,  it  is  assigned  a location. 

This  is 

25. 

explained  further  in  the  text. 

26. 

NEED(i) 

: Explicit  assistance  requirement  of 

the  case. 

27.  tos(i):  Amount  of  time  spent  on  scene  for  serving  need(i) 

tos (i)  = 0 for  search  only  and  tow  only  cases. 

28.  A(i):  Proportion  of  time  into  the  multi -resource  case 

completion  that  the  subsequent  resource  commences 


service.  (0  - A (i)  - 1) . 
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The  inputs  requred  to  operate  PCP  are  the  following: 

1.  CASE  FILE:  The  SAR  Assistance  Reports  have  been  processed 

through  the  Cleaning  Routines  and  the  inconsistences 
removed  (with  Coast  Guard  assistence) . The  Case  Assembly 
Processor  assembles  multi -unit  cases  and  prepares  the 
CASE  FILE.  The  CASE  FILE  thus  contains  all  cases  for  a 
given  district  single  unit  and  multi -unit,  sorted  on  date 
and  time  of  notification  (earliest  for  multi-unit  cases). 
Area  cases  which  required  resources  from  the  district  being 
exercised  are  also  included  and,  in  general,  can  be  treated 
as  multi -unit  cases. 

2.  C-130  TAPE:  The  C-130  TAPE  contains  all  cases  that  were 

served  historically  by  a C-130  aircraft,  from  a single 
air  station,  sorted  by  date  and  time  of  notification. 

3.  District  Location  Data: 

(a)  District  Origin:  All  case  locations  are  referenced 

to  an  inputted  district  origin;  (Origin  Latitude  and 
Origin  Longitude.) 

(b)  BETA:  Coefficient  for  calculating  distances.  (See 

next  section) . 

(c)  Unknown  Case  Location  Data: 
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conversion  of  data  from  the  ’’old"  (pre-1970  format  to  the  one  currently 
in  use,  but  not  conversely.) 

Some  of  the  data  for  the  simulation  can  be  taken  directly  from 
the  Assistance  Report,  while  other  data  had  to  be  devised  using 
straightforward  algorithms.  Below  is  a list  of  case  attributes 
developed  in  PCP  which  are  the  input  to  DEMGEN.  Some  of  these 
parameters  correspond  directly  to  the  pre-FYl970  SAR  data  format  as 
described  in  USCG  CCMDT  INST  3123. 9A  dated  31  March  1966.  (Note 
that  this  Preprocessor  is  designed  fgtr  the  pre-FY70  data  format 
and  that  modifications  must  be  made  for  any  other  format.) 
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The  inputs  requred  to  operate  PCP  are  the  following: 

1.  CASE  FILE:  The  SAR  Assistance  Reports  have  been  processed 

through  the  Cleaning  Routines  and  the  inconsistences 
removed  (with  Coast  Guard  assistence) . The  Case  Assembly 

^Processor  assembles  multi-unit  cases .and  prepares  the 

1 h 

CASE  FILE.  The  CASE  FILE  thus  contains  all  cases  for  a 

given  district, single  unit  and  multi -unit,  sorted  on  date 

and  time  of  notification  (earliest  for  multi -unit  cases) . 

Area  cases  which  required  resources  from  the  district  being 

exercised  are  also  included  and,  in  general,  can  be  treated 

as  multpL-unit  cases.  F iS (T 

dCg&t  ^ <^/3d 

2.  C-130 'TAPE:  The  C-130  TAPE  contains  all  cases  that  were 


3. 


served  historically  by  a C-130  aircraft,  from  a single 

air  station,  sorted  by  date  and  time  of  notification.  (U£*l£^> 

Pcf  ^ <2A  SC  r <L<~ 


District  Location  Data : y 

(a)  District  Origin:  All  case  locations  are  referenced 

to  an  inputted  district  origin;  (Origin  Latitude  and 
Origin  Longitude.) 

(b)  BETA:  Coefficient  for  calculating  distances.  (See 

next  section) . 

(c)  Unknown  Case  Location  Data: 
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i.  For  cases  occurring  in  the  district  with  no 

location  given,  a location  is  assigned  the  Cartesian 
coordinates  (x^  + Ax,  y^  + Ay)  from  the  historic 
primary  station,  i.  Both  Ax  and  Ay  are  user  inputs 
and  apply  for  the  entire  district.  The  coordinates 
(Xf,  y.)  are  also  input  for:  each  station,  i. 
ii.  For  cases  served  historically  by  a C-130  aircraft 
but  with  no  location  given,  a location  is  assigned 
corresponding  to  the  district  selected  via  Monte 
Carlo  techniques.  A distribution  of  C-130 
cases  across  the  districts  is  input  along  with  a 
C-130  case  centroid  location  for  each  district. 

(This  centroid  represents  that  location  where  most 
C-130  cases  occurred  in  that  district.) 

(d)  Search  Speeds:  For  each  resource  type,  L,  the  search 

speed,  SOA^(L)  is  required  to  calculate  TSM. 

(e)  Information  for  translating  the  assistance  rendered 
historically,  to  property  and  personnel,  into  the  needs 
of  the  case  used  within  the  simulation. 

(Note  that  the  special  cull  conditions  for  removing  certain 
cases, (such  as  communications  checks,) from  the  SARSIM  Case  File 
and  the  decision  point  for  distinguishing  between  a long  search  and 
a short  search  are  internal  to  the  program,  and  not  user  input.) 
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The  PCP  processes  a case  at  a time,  generating  the  proper 
parameters  relative  to  whether  the  case  is  single  resource,  multi - 
resourced,  or  a search  case.  Figures  (4)  through  (6)  illustrate 
the  algorithms  which  make  up.* the  PCP. 

Each  case  in  the  CASE  FILE  has  case  identifying  data, distressed 
unit  data  and  reporting  command  data  and  resource  data. 

If  the  case  is  historically  a multi-unit  case,  with  multiple 
command  reporting  data,  then  the  date  and  the  time  the  case  arrived 
to  the  system  becomes  the  earliest  time  a Coast  Guard  station  was 
notified  of  the  case.  This  is  the  minimum  value  of  the  set  of  Cl's, 
the  date  and  time  the  reporting  command  was  first  notified,  called 
MINC1.  This  Coast  Guard  station  or  the  earliest  reporting  command 
becomes,  for  the  time  being,  the  primary  station.  (The  primary  is  later 
recalculated  in  OPSIM  EXEC  as  the  closest  of  the  set  {P+A} , where  P is 
the  primary  and  A are  its  adjacents.) 

If  the  case  is  a single -unit  case  then  the  reporting  command 
becomes  the  primary  again  until  modified  by  the  OPSIM  EXEC. 

Those  cases  appearing  on  the  C-130  TAPE  must  have  their  district 
identified  prior  to  assigning  a primary  station.  For  each  of  these 
cases,  the  distance  from  the  case  location  to  the  District  Centroid 
of  each  district  is  calculated  and  that  district  corresponding  to  the 
minimum  of  these  distances  is  assigned. 

If  no  location  is  given  for  the  cases  appearing  on  the  C-130 
TAPE,  then  the  district  is  assigned  via  the  Monte  Carlo  of  the 
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Figure  4 
PCP  Flow  Chart 
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Figure  5 

PCP  Flow  Chart  (continuation) 
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Figure  6 

PCP  Flowchart  (Concluded) 
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district  in  accordance  with  an  inputted  frequency  distribution  of 
the  0130  cases  across  the  districts  of  interest. 

Once  all  the  0130  cases  have  been  assigned  a district,  the 
primary  station  can  then  be  detemnined.  If  the  case  has  been  assigned 
to  a district  other  than  the  one  being  exercised,  then  the  primary 
becomes  the  station  at  which  the  0130 !s  are  based.  (For  example,  on 
the  East  Coast,  Elizabeth  City  would  be  assigned  as  the  primary.) 

If  the  0130  case  occurs  in  the  district  being  exercised,  then  no 
primary  is  assigned.  Instead,  if  there  is  no  primary,  then  OP SIM 
EXEC  calculates  the  closest  Coast  Guard  station  in  the  district  and 
assigns  it  as  the  primary. 

For  each  case,  its  location  (latitude,  longitude)  is  converted 
to  Cartesian  coordinates,  (x,y)  relative  to  the  district  origin. 

(Origin  Latitude  and  Origin  Longitude.)  Latitude  and  longitude 
are  given  in  minutes.  BETA  is  the  length  in  nautical  miles  of  a 

3 

degree  of  longitude  at  the  district  origin. 

If  the  case  has  no  given  location,  then  a location  is  assigned 
some  inputted  distance  from  the  primary.  (This  scheme  is  not  used 
^ for  those  cases  from  the  C-130  TAPE).  Given  that  the  primary,  i,  is 
located  at  Cartesian  coordinates  (x^,  y^)  from  the  district  origin, 
then  the  case  is  assigned  the  location  (x^  + Ax,  y^  + Ay) . Both 

3 

Bowditch,  Nathaniel  U.  S.  Government  Printing  Office,  1966  corrected  print. 
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Ax  and  Ay  are  user  input,  and  hold  for  the  entire  district. 

If  the  case  is  from  the  0130  TAPE,  and  has  no  location,  then 
the  0130  Case  District  Centroid  is  assigned,  corresponding  to 
the  district  either  calculated  or  assigned  as  described  above. 

Next,  the  OPFAC  identification  numbers  are  replaced  by  a 
sequential  station  number,  STANO,  used  in  the  simulation. 

From  the  resource  data  records  of  a case,  the  total  search  time 
of  the  case,  D6T0T,  and  the  total  search  miles,  TSM,  are  calculated 
by  examining  the  hours  spent  searching  and  the  resource  type,  L, 
that  searched  historically.  That  is, 

D6T0T  = J D6(i),  where,  D6 (i)  is  the  hours  spent 

i 

searching  by  resource  i;  and, 

TSM  = 2 D6(i)  * SOA^CL),  where  SOA^CL)  is  the  search  speed 
th  i 

of  the  Ll  type  resource. 

The  variable  MILES,  the  distance  the  distress  is  located  off  shore, 
is  determined  in  the  following  fashion: 

1.  If  the  code  for  B16,  the  Type  of  Distress  Area,  indicates  the 
case  occurred  less  than  a 1/2  mile  off  shore,  then 

MILES  = 0.3  miles. 

2.  If  the  code  indicates  the  case  occurred  less  than  5 miles 
off  shore,  but  greater  than  1/2  mile,  then  MILES  = 3.0  miles. 
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3.  If  the  code  indicates  the  case  occurred  less  than  10 
miles  off  shore,  but  greater  than  5 miles,  then  the 
distance  is  taken  as  8.0  miles. 

4.  For  values  of  B16  exceeding  10  miles,  the  distance  is  the 
value  of  B16.  However,  if  B16  is  unknown,  then  MILES  = 10.0) 

The  severity,  S,  of  the  case  is  mapped  in  the  following  way  in 
an  attempt  to  model  properly  the  higher  urgency  of  responding  to  cases 
involving  high  danger  to  personnel.  Thus,  increasing  values  of 
severity  will  indicate  increasing  seriousness: 

1.  If  the  code  indicates  the  value  (1),  i.e.,no  immediate 
danger  to  personnel  or  property,  it  maps  to  a severity  level 
for  simulation  purposes  as  a (1) . 

2.  If  the  code  indicates  a (2),  i.e. , moderate  degree  of 
danger  to  property,  then  it  is  mapped  as  a (2) . 

3.  If  the  code  indicates  a (3),  i .e . , moderate  degree  of 
danger  to  personnel  and  property,  then  it  is  mapped  as  a (4). 

4.  If  the  code  indicates  a (4),  i .e . , serious , involving 
property  only,  then  it  is  mapped  as  a (3) . 

5.  Finally,  if  the  code  indicates  a (5),  i .e . , serious , 
involving  personnel  or  personnel  and  property,  then  it 
is  mapped  as  a (5) . 
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Each  case  input  to  OPSIM  requires  indicators  to  determine  if 
the  client's  location  is  unknown  and  a search  must  be  conducted  prior 
to  serving  any  of  his  needs.  A short  search  is  characterized  by 
a total  search  time,  D6TOT,  of  one-half  hour  or  less.  If  the 
situation  calls  for  a short  search,  it  is  performed  either 
by  the  first  resource  on  scene  or  by  a single  additional  resource, 
called  to  scene  by  the  resource  first  to  arrive  scene.  From 
the  resource  data,  the  earliest  resource  arriving  to  the  scene 
is  examined  to  see  if  it  historically  performed  the  search.  If  so, 
then  the  total  search  task  is  assigned  to  that  resource  and  if  not, 
then  an  additional  resource  must  have  been  called  in,  and  the  code 
for  short  search, S2,  is  set  to  a 2. 

If  D6T0T  exceeds  a half-hour,  then  is  coded  as  zero,  and  S^, 
the  average  number  of  resources  that  searched  for  an  extended 
period  is  determined  next.  (See  Figure  5.)  is  defined  as  the  ratio 
of  the  total  resource  time  spent  searching,  D6T0T,  to  the  daylight 
hours  of  search.  This  implies  that  the  developed  value  represents 
the  equivalent  resources  searching  in  parallel.  To  calculate  S^, 
the  elapsed  time  spent  searching  on  the  case,  tes,  must  be  found. 

For  each  responding  resource,  i,  D4FRST(i),  the  clock  time  resource  i 
completed  searching,  is  calculated  as  the  sum  of  D4(i),  the  time 
resource  i arrived  on  scene,  and  D6(i),  the  elapsed  time  resource  i 
spent  searching.  The  elapsed  time,  tes,  becomes: 

tes  = MAX  {D4FRST (i) } - Min  (D4(i)} 
i i 

4 

Although  not  parameterized,  this  value  may  be  changed  by  a simple 
program  modification. 
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Note  tes  includes  the  nighthours  within  the  elapsed  search  time 

of  the  case;  thus  the  nighthours,  NH,  must  be  calculated  and  sub- 
tracted  from  tes. 


The  hours  of  daylight  are  taken  as  14  hours.  If  tes  does  not 
exceed  14  hours,  then  NH  is  set  to  zero.  If  tes  is  between  14  and 
24  hours,  NH  becomes  tes  minus  14  hours.  If,  however, tes  exceeds 
24  hours,  NH  becomes  tes/2.4  or  the  proportion  of  tes  attributable 
to  night  time.  A constant  is  added  to  the  ratio  to  facilitate  rounding 
up  to  the  next  whole  resource.  The  brackets  [ ] indicate  truncation 
to  the  largest  integer.  Thus,  S:  is  given  by. 


s 


1 


where, 


D6T0T 


tes-NH 


+ .99 

J 


NH  - 0,  if  tes  - 14;  or 

NH  = tes  -14,  if  14  < tes  £ 24;  or 

NH  = tes/2.4,  if  tes  > 24 

Once  all  the  search  parameters  are  calculated  for  the  case,  the 
parameters  relative  to  the  serving  of  the  remaining  needs,  including 
tow  or  escort  (i.e.  non-search),  are  determined  next. 

The  time  each  resource  spends  on  scene,  tos (i) , serving  a 
need  other  than  search,  tow  or  escort  is  derived  from  the  resource 

From  the  data  base,  the  following  information  is  used:  D8 Ci)) > 

the  total  elapsed  time  spent  searching;  D3(i),  the  time  the  resource 
was  underway;  D4(i),  the  time  the  resource  arrived  on  scene;  and  D9(i) 
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the  number  of  sorties.  From  the  above,  the  expression  for  time  on 
scene  as  becomes: 

tos(i)  = D8(i)  - D6(i)  - 2 * D9  (i)  * (D4(i)  - D3(i)} 
Corresponding  to  the  time  on  scene  is  a specific  need,  NEED(i), 
for  each  resource  participating  on  the  case.  Again, each  NEED(i)  is 
a service  requirement  other  than  search,  tow  or  escort.  Sub- 
routine NEEDS  is  called  to  convert  the  historical  assistance  rendered 
to  personnel  (Dll)  and  property,  both  primary  (D12)  and  secondary 
(D13) , to  a single  coded  value  required  for  each  "need"  (and  for 
each  resource)  in  OPSIM.  These  translations,  the  basis  of  NEEDS,  are 
listed  in  Table  1.  Note  that  some  of  the  coded  needs  in  OPSIM  encompass 
a number  of  different  types  of  assistance  rendered.  The  reader  is 
referred  to  Section  III,  of  SRAS,  and,  in  particular,  the  Resource 
Capability  Matrix,  for  a description  of  those  resources  capable  of 
performing  these  needs.  Figure  7,  Subroutine  NEEDS,  illustrates 
the  decision  process  necessary  to  translate  the  assistance  rendered 
(reported  on  each  resource  card)  to  a single  need.  D^ , the  assisting 
resource  type,  is  queried  initially.  Personnel  aided  by  an  aircraft 
preempt  aid  to  property.  If  the  assisting  resource  is  an  aircraft 
and  Dll  is  positive,  then  the  need  becomes  the  translated  Dll. 

If  Dll  is  zero,  and  D12  is  positive,  then  D12  need  is  recorded.  If 
both  Dll  and  D12  are  zero,  then  the  need  becomes  18,  General  Assistance 
Rendered. 
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Table  1 

Assistance  Rendered;  Translation  to  Need 
If  Dll  is:  Then  the  Need  Becomes 

Personnel  in  Position  of  Peril, 

Rescued  or  Assisted  by: 


10: 

Attempted  Rescued-Failed 

16: 

Evacuate  People 

11: 

Boat  or  Vessel  Pickup 

12: 

Amphibian  Water  Landing 

13: 

Helicopter  Water  Landing 

14: 

Helicopter  Hoist 

15: 

Dropping/Providing  Equip . 

L: 

Provide  Equipment 

16: 

Aircraft  Landing  on  Land 

18: 

General  Assistance  Rendered 

17: 

Vectoring  Other  Unit  to  Assist 

Vector  Other  Unit 

18: 

Personnel  Assistance 

16: 

Evacuate  People 

Medical  Evacuation  of  Personnel  by: 

30: 

Boat  or  Vessel  Pickup 

31: 

Amphibian  Water  Landing 

32: 

Helicopter  Water  Landing 

33: 

Helicopter  Hoist 

f 

34: 

Diversion  of  Other  Unit 

5: 

Vector  Other  Unit 

35: 

Vehicle  or  Personnel 

18: 

General  Assistance  Rendered 

36: 

Aircraft  Landing  on  Land 

Medical  Aid  Rendered  to  Personnel  by: 
40:  Delivery  of  Doctor 
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Table  I (continued) 

41: 

Delivery  of  Medical  Supplies 

1: 

Provide  Equipment 

42: 

Diversion  of  Other  Unit  to  Scene 

5: 

Vector  Other  Unit 

43: 

Passing  Medical  Advice 

18: 

] 

General  Assistance 

Rendered 

44: 

Rendering  First  Aid 

18: 

General  Assistance 

Rendered 

97: 

Recovered  Bodies 

j 16: 

Evacuate  People 

99: 

Unclassified 

18: 

General  Assistance 

Rendered 

If  D12  or  D13  is: 

Then 

the  Need  Becomes: 

60: 

r 

Attempted  Salvage -Failed 

. . 

14: 

General  Assistance 

Rendered- 

Surface 

61: 

Fought  Fire 

4: 

Fought  Fire 

62: 

Dewatered 

1 

6: 

Dewatered 

63: 

Dewatered  and  Towed 

15: 

Tow;  Dewatered  and  Towed: 
Refloated  and  Towed 

64: 

Refloated 

7: 

Refloated 

65: 

Refloated  and  Towed 

1st 

Tow;  Dewatered  and 

Towed , 

66 

67 

68 
69 


Towed 

Refueled  or  Resupplied 

Escorted 

Tugbird  Tow 


70:  Delivered  Pump  by  Vessel 


Refloated  and  Towed 

9:  Refueled  and  Supplied 

* 


15:  Tow;  Dewatered  and  Towed; 

Refloated  and  Towed 

2:  Delivered  Pump  § Equipment 


*Need  is  10:  Surface  Escort,  if  B13  indicates  distressed  unit  is 

not  an  aircraft. 

Need  is  17:  Air  escort,  if  B13  indicates  distressed  unit  is  an 

aircraft. 

+or  Need  is  19:  Rescue  and  Tow  is  Dll  > 0 and  D1  not  an  aircraft. 
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Table  I (continued} 


71: 

Delivered  Pump  by  Air 

i 

72: 

Freed  Vessel  from  Ice 

8: 

Icebreaking 

73: 

Freed  Distressed  Unit 

13: 

1 

Freed  From  Position  of  Peril 

74: 

Made  repairs 

3: 

Made  Repairs 

75: 

Located  Property  and  Advised 
Owner 

| 12: 

Located  Property 

76: 

Recovered  Property 

ist 

Tow;  Dewatered  and  Towed; 
Refloated  and  Towed 

77: 

Navigational  Assist 

18: 

General  Assistance  Rendered 

78: 

Destroyed  Menace  to  Navigation 

14: 

General  Assistance  Rendered- 

Surface 

79: 

Stood  by 

11: 

Stood  by 

99: 

Unclassified 

18: 

General  Assistance  Rendered 
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If  the  assisting  resource  is  not  aircraft  and  Dll  is  greater 
than  zero  and  D12  or  D13  is  tow,  dewater  and  tow,  or  refloat  and  tow, 
then  the  need  is  coded  as  a 19,  rescue  and  tow.  If  D12  or  D13  is  not 
a tow,  dewater  and  tow  nor  refloat  and  tow,  then  assistance  to  personnel 
predominates,  and  the  need  becomes  the  translated  Dll  assistance 
rendered. 

If  the  assisting  resource  is  not  an  aircraft  and  both  Dll  and 
D12  ate  zero,  then  the  need  is  coded  as  a 14,  General  Assistance 
Rendered.  If  Dll  is  zero  but  D12  is  not,  then  D13  is  queried. 

If  D13  is  a tow,  dewater  and  tow,  or  refloat  and  tow,  then  the  need 
becomes  15,  tow,  dewater  and  tow,  or  refloat  and  tow.  If  D13  is  not 
a tow,  dewater  and  tow,  nor  refloat  and  tow,  then  the  need  becomes 
the  translated  D12. 

The  total  number  of  needs,  n,  is  determined  by  accumulating  the 
total  number  of  resources  other  than  those  which  searched,  towed 
or  escorted.  The  value  m is  the  number  of  resources  that  performed 
a tow  or  escort.  NN  is  determined  according  to  those  conditions 
presented  previously  in  Section  2C  on  page  [13]. 

In  order  to  simulate  the  degree  of  parallelism  in  the  service  of 
a case,  additional  case  parameters  had  to  be  extrapolated  from  the 
data  base.  First,  the  elapsed  time  spent  rendering  aid  (other 
than  search,  tow,  and  escort) ttQi  is  found.  For  each  resource  i on 
the  case,  D4FRST(i)  is  calculated,  as  described  previously.  (Recall, 
D4FRST(i)  is  the  time  that  resource  i complete  searching  (if  D6(i) 
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were  greater  than  zero)  assuming  search  commenced  immediately  upon 
arrival  on  scene  of  resource  i.)  In  addition,  the  time  resource  i 
completes  searching  for  the  client, (if  any  search  was  involved,) 
and  servicing  him,  designated  LVTM(i) , is  calculated  as  the  sum  of 
D4FRST(i)  and  tos  (i) . t can  then  be  calculated  thus: 

t = Max'  (LVTM(i) } - Min  {D4FRST(i)>. 
i i 

Next,  in  order  to  schedule  subsequent  arrivals  of  resources  to 
the  scene  of  the  SAR  incident,  A(i),  the  proportion  of  time  into 
case  completion  resource  i arrived  on  scene  to  serve  need  i,  is 
found: 

D4FRST(i)  - Min  {D4FRST  (i) } 

A(i)  = — 1 

t - tos  (i) 

For  the  first  resource  on  the  case,  A(i)  is  set  to  zero. 

Finally,  a,  the  degree  of  non-parallel  service  on  a multi 
resource  case  serving  needs  other  than  search,  tow  or  escort,  is 
calculated  as: 

t - Max  {tos  (i)  } 

i 

l tos(i)  - Max  (tos(i)} 
i i 

The  reader  is  referred  to  the  material  on  MRAS  for  a comprehensive 
discussion  of  A(i)  and  a. 

Once,  the  case  is  completely  processed,  it  is  output  on  the 
SARSIM  CASE  FILE,  the  input  to  DEMGEN.  When  the  end  of  file  (EOF) 
is  reached,  that  is  all  the  cases  on  the  CASE  FILE  and  the  C-130 
TAPE  have  been  processed,  PCP  halts. 
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It  is  stressed  that  the  case  attributes  have  been  developed 
from  the  data  base,  i.e.  the  CASE  FILE  and  the  0130  TAPE, 

Essentially  the  case  is  reconstructed  on  a time  line,  and  partitioned 
Into  the  general  order  of  search,  if  required;  service  of  needs, 
other  than  search,  tow  or  escort;  and,  finally,  tow  or  escort,  if 
required.  In  re-constructing  the  case  from  the  data,  inconsistencies 
in  the  recording  of  the  data  have  been  overcome,  so  that  the  case 
is  simulated  as  closely  as  possible  to  the  historical  past. 

D.  The  DEMGEN  Program 

The  main  objective  of  DEMGEN  Is  to  prepare  a chronological 
CASE  TAPE*  from  the  SARSIM  CASE  FILE,  which  was  an  output  from  the 
PCP.  The  user  may  choose  whether  the  ordering  should  confom  to 
past  history,  or  whether  randomness  Is  to  govern. 

The  first  option,  described  in  Volume  III  of  this  series  as 
a separate  program  called  HIST,  recapitulates  historical  precedent. 

The  user  specifies  inclusive  dates  of  interest  and  DEMGEN  creates 
a CASE  TAPE  listing  the  cases  of  a given  district  in  the  historical 
order  of  their  occurrence  during  the  period  of  interest,  along  with 
the  appropriate  case  parameters.  This  provides  a mechanism  for 
simulating  history,  thereby  enabling  a comparison  with  simulation 
results  for  OPSIM  with  the  corresponding  historical  outcomes.  Valuable 
insights  may  thus  be  afforded  into  the  simulation  and  validation  processes. 

*See  footnote  on  page  36. 
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The  user's  second  option  is  to  have  times  of  occurrence  determined 
by  random  processes.  This  option  may  be  applied  separately  to  the 
cases  occurring  within  the  district  and  also  to  those  historically 
served  by  0130  aircraft. 

This  second  option  preserves  the  correlation  between  an  individual 
case’s  attributes  and  its  relative  time  of  occurrence,  i.e.,the 
concept  here  supports  the  fact  that  certain  kinds  of  cases  occur 
at  certain  times  of  the  year  and  are  peculiar  to  the  time  of  week 
and  time  of  day.  Specifically,  the  output  from  PCP  retains  the 
historical  time  of  occurrence,  and  DEMGEN  sorts  these  cases  from  the 
SARSIM  CASE  FILE  by  predesignated  time  periods . These  time  periods 
are: 

1.  Weekday  Day  cases  in  Peak  season 

2.  Weekday  Night  cases  in  Peak  season 

3.  Weekend  Day  cases  in  Peak  season 

4.  Weekend  Night  cases  in  Peak  season 

5.  Weekday  Day  cases  in  Non-Peak  season 

6.  Weekday  Night  cases  In  Non-Peak  Reason 

7.  Weekend  Day  cases  in  Non-Peak  season 

8.  Weekend  Night  cases  in  Non-Peak  season 

Cases  with  all  their  attributes  are  stored  in  the  computer 
according  to  these  categories  or  "boxes".  That  is,  there  exists  a 
file  of  cases  for  each  of  the  above-listed  time  periods. 
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The  arrival  time  of  a case  is  generated  by  the  Monte  Carlo 
technique  from  a set  of  interarrival  time  distributions  calculated 
from  the  historical  times  of  occurrence.  Inter-arrival  times  of 
the  district  have  been  assumed  to  be  exponentially  distributed.  The 
concept  of  a set  of  these  distributions  attempts  to  model  the  changing 
arrival  patterns  over  the  day.  More  specifically,  for  each  of  the 
designated  time  periods,  a distribution  is  developed  for  each  hour 
in  the  time  period.  The  parameter  A^.  represents  the  average  arrival 
rate  for  the  ith  hour  of  the  jth  time  period.  This  parameter  is 
estimated  by  examining  the  number  of  arrivals  in  a given  hour  over 
the  time  period  of  interest  for  a given  district. 

For  the  random  generation  of  case  arrivals , a start  time  is  given 
to  initiate  the  generation  of  a CASE  TAPE.  Given  the  hour  and  date 
of  the  start  time,  a case  is  selected  randomly  from  the  proper  file 
corresponding  to  the  time  period.  (Since  sampling  with  replacement 
is  applied, the  case  is  not  removed  from  the  file.)  A random 
sample  is  then  drawn  from  the  proper  interarrival  time  distribution, 
using  that  corresponding  to  the  i^1  hour  in  the  time  period. 
The  reciprocal  of  this  sample,  At,  represents  the  time  from  the  start 
time  to  the  next  case  arrival.  Thus,  the  time  the  next  case  occurs 
is  the  start  time  plus  At;  this  time,  designated  OCCUR,  is  the  time 
the  case  arrives  to  the  system  or  requests  assistance.  OCCUR  is 
included  as  a case  attribute  and  is  output  onto  the  CASE  TAPE. 
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A new  sajriple  is  dram  from  the  distribution  corresponding  to 
the  time  period  of  the  latest  OCCUR.  The  next  time  of  occurrence  of 
a succeeding  case  becomes  the  sum  of  OCCUR  and  the  new  At.  From 
the  proper  time  period  file  corresponding  to  this  newly  updated 
OCCUR,  a case  is  then  randomly  drawn.  The  procedure  is  continued 
until  the  scenario  limits  have  been  reached,  i.e., either  the  stop 
time  of  the  simulation  or  a user  input  upper  limit  on  the  number  of 
cases  is  reached. 

It  is  desirable  to  prevent  the  generation  of  large  interarrival 
times.  This  situation  can  occur  quite  frequently  when  the  arrival 
rates  (A^)  are  small.  Without  any  limitation,  a small  A^  could 
result  in  several  time  periods  being  bypassed,  in  which  the  A^'s 
are  greater  than  that  A^.  used  to  generate  the  long  interarrival  time. 
Two  schemes  are  offered  to  the  user  to  help  prevent  this  from  happening. 

The  first  scheme  limits  the  generation  of  interarrival  times  to 
3/A^  hours,  truncating  the  asymptotic  tail  end  of  the  exponential 
distribution.  (The  cut-off,  3/A^.  was  chosen  since  this  value 
represents  approximately  951  of  the  area  under  the  exponential 
distribution  curve.)  Thus,  if  the  next  interarrival  time  exceeds 
3/A. . hours,  OCCUR  is  updated  to  OCCUR  + 3/A. . hours  and  the  process 

i]  ij 

continues  with  the  new  A.  . corresponding  to  the  new  time  period.  Also, 

ij 

if  any  A. . is  zero,  then  no  arrival  occurs  and  OCCUR  is  updated  one 
ij 

hour  and  the  new  A. . is  used  to  determine  the  time  of  the  next  arrival. 

13 
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The  second  scheme  checks  for  an  arrival  in  every  (i,  j) 
interval,  but  does  not  guarantee  an  arrival  in  that  interval.  If 
the  sampled  interarrival  time,  At,  exceeds  60  minutes,  then  a new 
sample  is  drawn.  The  process  is  continued  until  the  sample  drawn.  At 
is  no  more  than  60  minutes . Then  the  time  of  occurrence  of  this 
new  case  becomes: 

OCCUR  (New  Case)  = OCCUR  (Old  Case)  + 

(n-X)  *60  minutes  + A^, 

where  n is  the  number  of  samples,  and  At  is  less  than  60  minutes. 

Each  time  a sample  is  required,  it  is  sampled  from  a distribution 
with  the  A^  corresponding  to  the  interval  currently  being  investigated. 

A number  of  user  options  are  offered  to  develop  the  desired 
CASE  TAPE.  For  example,  mechanisms  are  incorporated  to  accommodate 
the  growth  of  cases  via  preselected  logic  switches  if  it  is  desired 
to  increase  the  case  population  across  all  the  cases  by  XI.  Similarly, 
any  set  of  A^’s  may  increased  by  XI,  or  any  specific  A^ 
can  be  increased  by  a given  percentage. 

For  more  specialized  growth  patterns  involving  particular  OPFAC's 
and  selected  case  parameters,  e.g. , clientele  type,  the  user  can 
input  his  desired  "IF"  statements  into  the  GROW  routine.  This  software 
"grows"  the  cases  randomly  at  the  proper  rate  and  inserts  them  in 
the  proper  files.  This  option  allows  the  most  flexibility  (other 
than  by  hand  selection)  in  providing  the  user  a mechanism  for  creating 
a desired  demand. 
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Figure  8 summarizes  the  DEMGEN  operations.  A random  number 
seed,  RNSEED,  may  be  input  by  the  user,  if  desired. 

Once  all  the  cases  have  been  generated  in  accordance  with  the 
desired  scenario,  those  C-130  cases  in  concert  v/ith  this  scenario 
are  inserted  chronologically  with  the  cases  already  generated  to 
produce  the  CASE  TAPE,  if  the  historical  date  option  for  C-130 
cases  is  taken.  Should  it  be  desirable  to  merge  a Scenario  Tape 
with  the  CASE  TAPE  to  produce  the  final  DEMAND  TAPE,  this  can  be  done 
by  writing  a simple  merge  routine.  If  no  SCENARIO  TAPE  exists,  the 
CASE  TAPE  obviously  becomes  the  input  to  OPSIM. 
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DEMGEN  Flow  Chart  - Figure  8 
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3.  OPSIM  The  Ooerational  Simulator  of  SARSIM 

..I,..  . -p.  «...  „ ii  -V  fc— , ■>--  ■.  ..  m ^■•-,11  ^ ..  1 4J  1 c - - u 

Individual  cases  are  processed  through  OPSIM  using  the  data  on 
the  exogenous  DEMAND  TAPE  supplied  by  PREPRO.  If  required,  a long-search 
is  simulated,  followed  by  assignment  of  one  or  more  resources  to  satisfy 
needs  for  sendees  other  than  search.  (It  should  be  recalled  that  location, 
needs  and  other  case  parameters  of  simulated  cases  are  based  on  historical 
occurrences.)  The  overall  structure  of  OPSIM  is'  included  in  Figure  (2)  on 
page  35. 

The  OPSIM  EXEC  first  examines  the  parameters  of  the  presented  case 
before  passing  control  to  the  appropriate  subroutine.  In  addition,  the 
OPSIM  EXEC  calculates  the  distance  of  the  case  from  the  historically- 
designated  primary  station  and  also  from  adjacent  stations,  choosing  the 
closest  of  these  as  the  primary  station  for  the  simulation:  this  is  con- 

sidered to  be  the  station  initially  notified  of  the  case  and  which  has 
primary  responsibility  for  responding.  For  those  cases  which  historically 
had  no  primary  station  or  a non-primary  station,  the  OPSIM  calculates 
the  nearest  possible  primary  station  in  the  district. 

If  there  is  a single  client  need  (other  than  search) , control  is 
passed  to  the  Single  Resource  Assignment  Subroutine  (SRAS) ; the  Multi 
Resource  Assignment  Subroutine  (MRAS)  is  called  if  there  are  two  or  more 
needs  to  be  satisfied.  For  each  of  these  assignments,  the  service  is 
simulated  in  the  Service  Subroutine  (SS) . After  each  case  has  had  its 
needs  satisfied,  the  Service  Subroutine  calculates  summary  statistics  for 
the  Standard  Output.  Long  search,  however,  has  specialized  calculations, 
handled  within  the  Search  Assignment  and  Service  Subroutine  (SASS) . 
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For  the  assignment  of  resources  in  SRAS  or  MRAS,  OPSIM  considers 

both: 

(a)  Case  attributes,  such  as  needs  to  be  met,  case  severity, 
environmental  factors,  physical  characteristics  of  the  vessel 
in  distress  and  its  location;  and 

(b)  Resource  attributes,  such  as  status,  location,  ability  to 
satisfy  the  client's  needs,  ability  to  operate  in  the  given 
environment,  and  cost  factors. 

Resource  selection  in  SRAS  and  MRAS  is  based  on  considerations  of 
cost  to  vector  a capable  resource  to  the  scene  of  the  incident,  time  to 
transit  to  the  scene,  and  case  severity.  In  contrast,  resource  selection 
in  SASS  also  entails  consideration  of  the  cost  for  a capable  resource  to 
cover  the  search  area,  the  time  required  to  cover,  and  severity  conditions. 
For  both  search  and  the  satisfaction  of  other  needs,  the  set  of  resources 
eligible  for  consideration  consists  of  those  at  the  primary  station  and 
its  adjacent  stations,  as  well  as  the  air  stations  and  cutters  covering  the 
primary  station. 

The  four  major  subroutines,  SRAS,  MRAS,  SASS  and  SS,  are  described, 
in  that  order,  in  the  sections  which  follow. 

A.  The  Single  Resource  Assignment  Subroutine  (SRAS) 

(1)  General  Description 

A large  fraction  of  SAR  incidents  are  served  by  a single  resource. 

For  SARSIM,  the  Single  Resource  Assignment  Subroutine  (SRAS)  forms  an 
ordered  set  of  capable  resources  which  could  satisfy  a single-need  case, 

The  major  steps  are  outlined  in  Figure  (9) . The  ordering  depends  on  the 
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time  and  cost  of  transiting  to  the  scene  for  each  considered  resource, 
as  well  as  policies  for  assignments  prescribed  by  the  user.  In  particular, 
"queue  discipline"  and  "server  discipline"  must  be  specified  to  determine 
when  service  should  be  interrupted  for  cases  of  higher  priority  and  the 
extent  to  which  nearby  stations  interact  with  one  another.  Further  de- 
tails of  assignments  and  service  will  be  presented  in  a later  section. 

(2)  Required  Inputs 

Some  of  the  inputs  required  in  the  exercise  of  SRAS  are  supplied  from 
PREPRO;  others  must  be  furnished  by  the  user.  The  case  attributes,  from 
PREPRO,  may  be  grouped  as  follows  to  show  where,  within  the  total  simu- 
lation, they  come  into  play: 

(a)  Operational  Capability  Factors,  which  determine  whether  a 

resource  type  is  capable  of  servicing  a particular  need,  de- 
pending on  the  values  of  the  following  attributes: 

(i)  Location  of  the  case 

a.  Case  coordinates 

b.  Distance  off  shore 

(ii)  Need(s)  of  the  case  (e.g.,  tow,  dewater  and  tow, 
refloat  and  tow,  evacuate  personnel  on  board,  provide 
equipment,  deliver  pump,  make  repairs,  fight  fire,  etc.) 

(iii)  Type  of  distressed  unit 

(iv)  Length  of  distressed  unit 

(v)  Number  of  personnel  on  board  distressed  unit 

(vi)  Sea  swell 

(vii)  Wind 
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(viii)  Visibility 
(ix)  Air  Temperature 

(b)  Supplementary  Factors  - Case  attributes  (i)  and  (ii)  below 

affect  the  Operational  Simulator;  (iii)  and  (iv)  provide  additional 
information  for  the  Postprocessor. 


(i) 

Time  of  occurrence,  OCCUR 

(ii) 

Severity  of  the  case,  S. 

(iii) 

Nature  of  distress  (case  type) 

(iv) 

Value  of  the  vessel 

The  user  must  specify  the  following  inputs  to  OPSIM  for  each 
simulation  run: 

(c)  Station  Inputs  - For  each  station  in  the  district: 


(i) 

Location  of  the  station 

(ii) 

A list  of  the  station’s  "feasible”  adjacent  stations, 
that  is,  those  stations  adjacent  to  the  primary  station 
(including  surface  patrol  areas)  with  resources  that 
might  be  sent  to  serve  a case  In  the  operating  area 
of  the  primary  station. 

(iii)  A list  of  the  aircraft  stations  and  responsible  cutters. 


(iv) 

(Responsible  cutters  are  handled  exactly  like  stations 
in  that  a cutter  is  a station  in  itself  which  can  serve 
cases  in  the  primary  station’s  area.) 

Station’s  Resource  Matrix,  including  the  number  of  each 
resource  type  attached  to  the  station;  initialization 
status  data  >i»e.,  busy  or  idle;  and  location. 
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(v)  Crew  Manning  Level  as  it  varies  over  the  day  and  day 
of  week  and  the  crew  level  at  which  a standby  is 
called. 

(d)  Resource  Type  Inputs 

For  each  resource  type,  the  following  inputs  are  required  from  the 

user: 

(i)  Resource  Capability  Matrix  - This  matrix,  prepared  by 
the  user  in  binary  code,  indicates  the  capability  of  each 
resource  type  to  respond  to  a case  for  each  operational 
capability  factor  and  environmental  factor  permitted. 

Figure  10  illustrates  the  form  of  this  matrix.  Capability 
is  assessed  as  being  full  1,  or  absent,  0,  relative  to 

each  case  attribute.  Figure  10  is  presented  for  illustrative 
purposes  only;  these  assessments  can  be  varied  by  the 
user. 

(ii)  Resource  Reliability  - For  each  resource  type,  a coefficient 
defines  the  probability  of  '’failure"  immediately  prior 

to  assignment.  Failure  may  result  from  unexpected  mal- 
function, inoperability  due  to  planned  maintenance, 
or  both. 

(iii)  Resource  Speeds  of  Advance  - For  each  type  of  surface 
resource,  the  speed  can  be  modified  as  a function  of  sea 
swell . For  air  resources , modification  for  wind  was  con- 
sidered unnecessary.  The  resource  speed  of  advance  is  used 
to  calculate  the  time  for  a resource  to  vector  to  the  scene. 
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FIGURE  10 

RESOURCE  CAPABILITY  MATRIX 

W 

Y 

M T 

R M 

U U U B / H H 

TTT  M M/WWWWW  CUHH 


CASE  ATTRIBUTES  B 

B 

B 

L L 

M 

P 

P 

Y 

M 

H 

1 

1 

5 

H 

(L) 

CM) 

Cu) 

B B 

S 

B 

B 

T 

E 

E 

3 

6 

2 

3 

40 ! 

30’ 

17' 

44/52  36  B 95 

82 

L 

C 

C 

0 

E 

A 

F 

Swell 


0-5' 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

5-10* 

1 

0 

0 

1 

1 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

10-20' 

0 

0 

0 

1 

1 

0 

1 

1 

0 

1 

1 

1 

1 

1 

1 

20' 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1 

1 

1 

1 

Wind 


< 60 

Kts . 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

> 60 

Kts. 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

1 

Visibility 


< 1/4  Mile 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1 

1 

1/4  - 1/2  Mile 

1 

0 

0 

1 

0 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

> 1/2  Mile 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

-73- 


FIGURE  10  (continued)  (2) 
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FIGURE  10  Continued)  (3) 
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FIGURE  10  (continued)  (4) 
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(A  search  speed  is  also  included  for  each  resource  type, 
to  be  used  in  the  search  routine,  SASS) . 

(iv)  Resource  Operating  Cost  - This  is  the  dollar  cost  per 
hour  for  operating  each  resource  type  and  is  used  to 
calculate  the  cost  for  each  resource  to  vector  to  the 
scene  for  subsequent  ordering  of  resources. 

(v)  Resource  Type  Ranking  - This  is  a relative  (ordinal) 
ranking  among  the  resource  types  by  some  user-determined 
cost.  It  can  be  used  in  lieu  of  operating  cost  in  the 
final  ordering  of  resource  types  prior  to  assignment. 

(vi)  Resource  Underway  Time  - This  is  the  time  for  a particular 
resource  type  to  get  underway  from  its  homeport.  (Note: 
resources  on  patrol  should  have  no  underway  time,  or  start- 
up time.  Small  boats  and  aircraft  may  have  a short  time 

to  get  underway,  but  larger  surface  resources  may  require 
several  hours.)  DLAY(L)  for  the  L^1  resource  type  is  input. 

(e)  Tolerance  Time  - This  reflects  the  maximum  acceptable  waiting 
time  for  a client,  measured  from  first  notification  of  the 
incident.  For  each  severity  level,  S,  a time,  TOL(S) , is  input. 

(If  possible,  assignments  will  be  made  for  resources  which  can 
arrive  on  scene  within  the  limits  set  by  TOL(S).) 

(f)  Resource  Assignment  Policy  - The  user  chooses  from  a set  of  re- 
source assignment  policies,  each  of  which  describes  a pre- 
ferential ordering  of  the  desirability  of  calling  an  adjacent 
station  and  the  desirability  of  interrupting  another  case. 

These  policies  define  the  server  discipline  in  the  simulation. 
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(3)  SRAS  Logic 

When  a single-need  case  is  processed  in  0PS1M,  control  passes  to 
SRAS  and,  subsequently,  to  the  preselected  resource  assignment  policy 
(RAP) . The  Service  Subroutine  (SS)  is  executed  to  simulate  client 
service  time  and  resource  service  time.  (SS  is  discussed  in  a later  section.) 

Figure  11  shows  the  flow  of  operations  of  the  first  major  step  in 
SRAS,  selecting  an  ordered  set  of  capable  resources.  Figure  12  illustrates 
one  of  the  resource  assignment  policies.  It  may  be  helpful  to  refer  to 
these  flow  charts  during  the  ensuing  discussion. 

(a)  Selecting  an  Ordered  Set  of  Capable  Resources  to  Service  a Case. 
Briefly,  the  problem  of  selecting  an  ordered  set  of  capable  resources 
is  accomplished  by  considering  the  case’s  attributes,  the  resource's 
capability  to  satisfy  the  case's  requirements,  the  relative  distances 
between  candidate  resources  and  the  case,  the  cost  involved  in 
vectoring  each  resource  and  the  time  for  the  resource  to  get  underway.' 
Figure  11  indicates  the  flow  of  operations. 

Step  1:  The  first  step  is  to  determine  those  resource  types 

which  are  capable  of  serving  the  case.  The  Resource  Capability 
Matrix  (Figure  10)is  accessed  for  the  appropriate  rows  correspond- 
ing to  applicable  value  for  each  of  the  case's  attributes.  These 
rows  are  then  "ANDed"  by  the  Boolean  operation,  and  the  result, 
a binary  list,  indicates  capable  resources.  A zero  indicates 
that  the  resource  is  incapable  of  serving  this  case;  a one  indi- 
cates capable  resources.  A zero  indicates  that  the  resource  is 
incapable  of  serving  this  case;  a one  indicates  capability. 


-78- 


Step  6 


Figure  11 

Select  An  Ordered  Set  of  Capable  Resources 
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Figure  12 

Modeling  the  Assignment  of  a Resource  to  Service  Case 
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To  illustrate,  consider  the  following  case:  A 42’  boat  with  3 

people  on  board  requires  a tow  from  15  miles  offshore.  The  environ- 
mental conditions  include  air  temperature  of  68°,  visibility  beyond 
a 1/2  mile,  wind  at  20  knots,  and  swell  of  6'. 

From  the  Resource  Capability  Matrix,  the  appropriate  rows  are 
selected  (rows  2,  5,  9,  11,  15,  33,  37).  Now,  "ANDing"  these  rows, 
the  result  is: 

100110110110000 

Interpreting  this  result,  we  find  that  the  resource  types  which  can 
serve  the  case  include: 

UTB  (L) 

MLB  (44  $ 52) 

MLB  (36) 

WPB  95 
WPB  82 
WMEC 
WHEC 

Step  2:  The  second  step  is  to  retrieve  from  the  Station  Resource 

Matrix  for  the  station,  its  adjacents,  its  covering  aircraft 
and  patrol  boats,  those  resources  corresponding  to  the  capable 
resource  type  list.  It  should  be  noted  that  the  station  referred 
to  above  is  also  a case  attribute,  and  is,  therefore,  known  at 
the  time  the  case  enters  SRAS.  This  station  does  not  necessarily 
answer  the  case.  It  is  used  as  a mechanism  for  identifying  a 
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subset  of  resources  within  the  entire  district,  which  could 
answer  the  case.  The  result  is  a list  of  capable  resources 
which  are  within  "answering"  range. 

Step  5:  Using  the  location  of  the  case  and  the  locations  of 

the  capable  resources  found  in  step  2,  the  time  it  takes  each 
resource  in  the  list  to  vector  to  the  expected  location  of  the 
case,  t er,(K),  is  computed. 

Step  4:  Since  the  case  enters  the  system  with  a given  severity, 

S,  the  tolerance,  TOL(S),  can  be  compared  to  t (K)  + DLAY(L), 
where  tvec00  is  calculated  in  step  3 and  DLAY(L)  is  retrieved  for 
each  resource  (if  at  homeport) . If  there  are  no  t C(K)  + 
DLAY(L)  which  are  less  than  or  equal  to  TOL(S),  then  step  5 
is  executed.  Note:  DLAY(L)  is  used  only  if  the  resource 

is  to  be  vectored  from  its  homeport  to  the  expected  case 
location . 

Step  5:  The  capable  resources  for  which  t (K)  + DLAY(L)  does 

not  exceed  TOL(S)  are  ordered  by  increasing  cost.  The  resources 
which  cannot  meet  the  TOL(S)  criteria  are  ordered  on  increasing 
t (K)  + DLAY(L).  These  two  lists  are  then  merged,  first 

V CL 

by  cost  and  then  by  time.  As  part  of  the  design,  the  user  is 
offered  two  methodologies  for  ordering  capable  resources.  It 
may  be  recalled  that  the  user  may  opt  for  calculating  the  cost 
for  each  capable  resource  to  get  underway  and  vector  to  the 
expected  location  of  the  case,  with  the  result  used  in  the  order- 
ing process;  alternatively, he  may  choose  the  resource  type  rank- 
ing to  order  the  capable  resources.  The  selection  of  the 
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methodology  is  under  use  control.  Once  the  ordering  has 
been  completed,  the  preselected  resource  assignment  policy 
is  then  executed  with  this  final  ordered  capable  resource 
list. 

Step  6:  This  step  is  entered  if  no  resources  satisfy 

tyec (K)  < TOL(S).  The  capable  resource  list  from  step  3 is 
ordered  on  increasing  t C(K)  + DLAY(L).  Cost  is  not  a 
factor  in  this  situation. 

(b)  Resource  Assignment  Policies 

These  policies  offer  the  user  the  opportunity  to  select  a set  of 
rules  which  govern  the  operational  procedure,  at  the  primary  station,  in 
calling  for  assistance  from  its  adjacents,  covering  aircraft  and  cutters. 
(Covering  aircraft  and  cutters  can  be  included  for  every  station,  pri- 
mary or  adjacent.)  These  plans  offer  a wide  diversity  of  operations, 
from  pure  station  autonomy  to  an  interactive  station  grouping  policy. 

In  addition,  these  policies  offer  the  user  the  opportunity  to  test 
various  interrupt  rules  in  the  resource  selection  process. 

Each  policy  contains  a decision  block  which  ascertains  the 
status  of  a capable  resource,  busy  or  idle;  this  also  considers  crew 
availability.  If  a crew  is  not  available,  the  resource  cannot  be 
assigned.  More  precisely,  this  decision  block  could  be  entitled  "Is 
there  an  idle  resource  and  an  available  crew?"  This  block  will  be  dis- 
cussed further  in  a later  section. 

Basically,  each  policy  assigns  an  idle  capable  resource  with  an 
available  crew  to  the  incoming  case.  Some  policies  allow  the 
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interrupt  of  a busy  resource  if  the  incoming  case's  priority  is 
higher  than  those  cases  already  being  served. 

A policy  is  preselected  through  the  user  inputs,  and  is  called 
via  a logic  switch.  Using  the  logic  switch  scheme,  additional  plans 
can  be  designed,  added,  and  offered  to  the  user.  Policy  1 is  detailed 
here  in  the  text  as  an  example  . The  additional  plans  offered 

are  outlined  in.  the  text  below. 

(i)  Resource  Assignment  Policy  1 (RAP  1) 

Policy  1 considers  the  idle  resources  at  the  primary  and 
adjacent  stations  sequentially,  then  considers  interrupting 
busy  resources  at  the  primary  and  adjacents  sequentially 
if  the  new  case  has  a higher  priority  than  those  cases 
already  undergoing  service  by  these  stations.  Figure  12 
shows  the  logic  of  this  policy. 

Step  1:  Examine  the  idle  resources,  R's,at  the  primary 

station,  P.  (Primary  includes  covering  aircraft  and  cutters.) 
Select  the  first  idle  resource  from  the  Ordered  Capable 
Resource  List.  Proceed  to  Step  6 for  service  of  the  case. 

Step  2:  If  there  are  no  idle  resources  at  P,  examine  the 

idle  resources  at  all  of  P's  adjacent  stations.  Select  the 
first  idle  resource  at  the  adjacent  stations,  A,  from  the 
Ordered  Capable  Resource  List.  Proceed  to  Step  6 if  one 
is  found. 

Step  3:  If  there  are  no  idle  resources  at  either  P or  A,  and  if 

the  case  has  a higher  priority  than  those  cases  being  served 
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at  P or  A,  then  interrupt  a busy  resource  at  P,  serve  the 
case  in  step  6,  and  queue  the  interrupted  case.  (The  wait 
time  in  the  system  of  the  interrupted  case  and  his  interrupt 
count  are  updated  for  output  purposes.)  The  interrupted  case 
is  treated  as  a new  arrival  to  the  system  by  subroutine  QUEUE, 
which  queues  the  interrupted  case,  (if  possible  another  capable  re- 
source is  located  to  serve  the  interrupted  case.)  QUEUE  updates 
and  records  the  following  information  for  output  purposes: 
a.  NOINT:  The  number  of  times  interrupted. 

NQUE:  The  number  of  times  case  enters  a queue. 

REA:  The  (first)  reason  for  being  placed  in  the  queue. 

PRI,  the  priority  of  the  case  is  increased  by  IDELTA  (user 
input)  to  give  some  preference  to  interrupted  cases. 

Step  4:  Step  4,  at  A,  is  analogous  to  step  3 at  P;  it  is 
executed  if  either  an  idle  resource  cannot  be  found  at  P or 
A,  or  a busy  resource  cannot  be  interrupted  at  P.  If  a re- 
source cannot  be  interrupted  at  A,  proceed  to  step  5. 

Step  5:  Queueing  the  case  delays  the  start  of  the  service 

of  a new  case  or  prolongs  an  interrupted  case.  A case  is  served 
when  a capable  resource  becomes  idle  via  EXQ  subroutine.  If 
the  arriving  case  is  of  lower  or  equal  priority  than  others 
undergoing  service,  it  must  wait  for  a capable  resource  to  become 
idle.  A non- interrupted  queued  cane  retains  its  original 
arrival  time  to  the  system.  The  interrupted  queued  case  takes 
the  time  of  interrupt  as  its  arrival  to  the  system.  (This  , 
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in  effect,  causes  the  simulation  to  find  an  idle  capable 
resource  for  the  interrupted  case.) 

Step  6:  Control  is  passed  to  the  Service  Subroutine  (SS) 
once  the  resource  has  been  assigned.  The  ©lapsed  times  for 
the  resource  to  get  underway,  vector  to  the  case,  serve  the 
case  and  return  are  simulated  in  this  routine. 

(ii)  Additional  Resource  Assignment  Policies 

Most  of  these  policies  model  a number  of  "server  disciplines," 
such  as  a queue  discipline  other  than  priority  interrupt. 

These  policies  range  from  complete  station  autonomy  to 
station  grouping, 

a.  RAP  2:  This  policy,  considered  to  be  similar  to  the  current 

operational  procedure,  examines  the  idle  resources  at 

P;  considers  interrupt  at  P;  examines  idle  resources  at 
A;  considers  interrupt  at  A;  queues  the  case  or  the 
interrupted  case;  exits  to  SS.  Briefly,  the  steps  are: 

P;  P Interrupt ;A;  A Interrupt;  Queue. 

b.  RAP  3:  This  policy  groups  the  primary  station  P,  and  the 

adjacent  stations  A.  The  steps  are:  (P  + A) ; (P  + A) 

Interrupt;  Q. 

c.  RAP  4:  This  policy  models  station  autonomy  in  that  the 

primary  P is  considered  alone.  The  steps  are:  P;  P Interrupt; 

Q. 

d.  RAP  5:  This  policy  considers  no  interrupt  and  station 

autonomy.  Priority  ordering  is  allowed  in  the  queue.  The 
steps  are:  P;  Q. 
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e.  RAP  6:  This  policy  is  only  applicable  for  multi- 
resource  and  search  cases.  The  steps  are:  P;  A;  Q. 

This  is  further  described  in  the  MRAS  documentation. 

Note,  a simple  first-in  first-out  (FIFO)  queue  discipline  can 
be  modeled  within  each  policy  by  letting  the  priority  of  all  cases  take 
on  the  same  value.  This  could  be  done  with  a minor  modification  to 
PCP  in  PREPRO. 

(c)  Resource  Idle  and  Operational  and  Crew  Availability  (RIOCA) 

Within  each  resource  assignment  policy,  the  question  of  idle 
resource  occurs  at  the  primary  station  in  resource  assignment  policies 
1,2,  3,  4,  5 and  at  the  adjacent  stations  in  policies  1,  2,  3 and  6. 

This  takes  into  account  the  operational  status  of  the  resource  and  the 
availability  of  the  crew.  That  is  to  say,  when  the  ordered  capable 
resource  list  is  queried,  in  the  preselected  resource  assignment  policy, 
the  question  of  on-line  failure  of  the  resource  type  and  crew  availability 
at  the  station  to  which  the  resource  is  attached,  is  also  asked.  (See 
Figure  13  for  the  flow  of  operations.)  If  the  resource  is  idle,  control 
passes  to  the  assessment  of  operability  of  the  resource,  step  1.  This  is 
accomplished  via  Monte  Carlo  and  comparison  of  the  sample  with  the  resource’s 
reliability  coefficient.  Reliability  is  a function  of  resource  type.)  If 
the  resource  is  operational,  control  passes  to  step  2,  which  queries  the 
crew  status  at  the  station  to  which  the  resource  is  attached.  If  a 
crew  is  immediately  available,  the  crew  is  assigned  to  the  resource  and 
the  resource  is  assigned  to  the  case.  A call  to  subroutine  SS  is  then 
made.  If  the  crew  is  not  immediately  available,  a standby  crew  is  called 
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up  with  a given  delay  time  (if  provided  for  by  the  user) . If  the 
resource  is  not  idle  or  if  the  crew  is  not  available,  control  is  passed 
back  to  the  preselected  resource  assignment  policy,  RAP,  where  an 
attempt  is  made  to  find  a capable  resource  at  the  primary  (or  adjacent) 
station  (depending  on  the  RAP) . Again,  an  available  crew  is  also 
sought  in  RIOCA  along  with  a determination  of  the  resource's  status 
and  operability. 

The  user  of  the  simulation  is  offered  the  option  of  including 
the  policy  of  calling  up  a crew  which  Is  on  standby  by  means  of  a set  of 
codes  for  the  variable  CL.  If  CL  is  set  to  -1,  the  user  excludes 
the  policy  of  call  up.  If  the  user  selects  0 or  1 for  the  value  of  CL, 
then  a standby  crew  is  called  when  the  number  of  crews  available  (and 
not  busy)  reach  the  preselected  level,  0 or  1.  Checks  are  included 
in  the  program  so  that  only  a single  standby  is  called  per  case. 

B.  The  Multi -Resource  Assignment  Subroutine  (MRAS)  of  OPSIM 

(1)  General  Description 

This  section  describes  the  assignment  and  scheduling  of  resources 
to  aid  those  SAR  cases  with  two  or  more  needs,  exclusive  of  the  require- 
ment for  search.  (Assignment  of  resources  for  the  search  need  is 
simulated  in  SASS,  described  in  Section  3C,  beginning  on  page  101.) 

The  Multi -Resource  Assignment  Subroutine  (MRAS)  may  simulate  the  assign- 
ment of  two  or  more  resources  from  a single  responding  station,  as  well 
as  resources  assigned  from  two  or  more  responding  stations. 

Resource  assignment  in  MRAS  is  based  on  such  case  attributes  as 
client's  needs,  case  severity,  environmental  factors,  physical  characteristics 
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of  the  unit  in  distress , and  case  location.  In  addition,  resources  are 
examined  on  the  basis  of  their  capability  to  serve  the  case  needs, 
ability  to  operate  under  the  environmental  conditions,  and  the  status, 
location  and  cost  of  each  resource. 

Paralleling  the  dynamics  of  search  and  rescue,  clients  are  served 
in  the  simulation  in  the  following  general  order  of  need:  if  required, 

the  client  is  located  through  search;  any  needs  beyond  search  are 
served  on  scene,  if  possible;  finally,  if  required,  the  client  is  towed 
or  escorted.  Multiple  services  other  than  hand-off  tows  and  escort  may 
be  performed  simultaneously,  in  sequence,  or  some  intermediate  combination 
of  series  and  parallel  operations. 

To  minimize  scheduling  problems  for  several  resources  to  serve 
multiple  needs  other  than  search  or  tow,  the  simulation  treats  each 
need  of  a multi -resource  case  as  a new  arrival  into  the  system.  This 
is  equivalent  to  converting  a multi -resource  case  into  a set  of  single 
resource  cases,  each  one  with  an  associated  arrival  time  and  service 
need.  Details  of  scheduling  are  provided  in  section  (3)  of  MRAS,  below. 

Two  difficult  problems  arose  in  MRAS  with  regard  to  distinguishing 
between  single  and  multiple  needs.  On  the  one  hand,  there  are  operational 
situations  where  resource  selection  is  based  on  the  capabilities  of  a 
single  resource  to  service  several  needs.  Conversely,  a single  need 
may  be  partitioned  so  that  several  resources  must  be  assigned  to  service 
it.  This  latter  problem  is  posed,  for  example,  when  several  resources 
are  sent  to  fight  a major  (but  single)  fire. 

To  facilitate  the  handling  of  the  first  type  of  problem,  multiple 
needs  served  by  a single  resource  were  treated  as  a single  need  in  the 
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simulation.  The  partitioning  of  a need  to  justify  assigning  several 
resources  was  not  modeled;  rather,  a one-to-one  correspondence  exists 
between  the  number  of  resources  historically  assigned  to  the  case  and 
the  number  of  needs  simulated  in  OPSIM. 

Since  the  multi -resource  case  is  basically  a set  of  single  resource 
cases  with  associated  needs,  MRAS  utilizes  the  fundamental  logic  of 
the  Single  Resource  Assignment  Subroutine  (SRAS) . An  ordered  set  of 
capable  resource  types  for  each  need  of  the  case  is  found,  as  in  SRAS; 
a resource  is  assigned  from  this  set  according  to  a strategy  selected  by 
the  user,  or  in  the  case  of  station  autonomy  by  setting  a user  switch. 

Each  strategy  defines  the  ’’queue  discipline”  (e.g.,  priority  interrupt) 
and  ’’server  discipline”  (e.g.,  level  of  station  interaction). 

Each  multi-need  case  is  first  partitioned  into  a set  of  single 
resource  cases.  A subroutine  then  creates  the  associated  arrival  times 
for  each  member  of  this  set  according  to  the  time  required  on  scene  to 
serve  the  need,  and  the  degree  of  parallel  service  of  the  needs  of  the 
case.  The  initial  arrival  of  the  case  to  the  system  is  preserved  for 
the  first  need. 

Each  case  has  an  ordered  set  of  needs,  created  in  PREPRO.  Condition- 
ality of  needs  is  preserved  partially  by  the  macroscopic  ordering  approach 
to  handling  the  case's  search  requirement,  its  needs  beyond  search,  and, 
finally,  the  tow  or  escort  need,  if  necessary.  However,  the  needs  other 
than  search,  tow  and  escort  are  considered  independent,  and  no  hierarchical 
order  is  preserved  except  that  they  may  be  ordered  in  time,  according  to 
the  case  history.  To  explain, those  needs  other  than  search  and  tow 
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(or  escort) , which  are  treated  independently,  can  be  queued  in  the 
simulation  and  served  out  of  historical  order. 

During  the  service  of  a multi -resource  case  an  attempt  is  made 
to  provide  continuous  coverage  of  the  client.  This  is  simulated  in  the 
Service  Subroutine,  SS,  but  cannot  be  guaranteed  should  a case  with 
higher  priority  arrive  to  the  system  and  preempt  a multi -resource  case 
being  covered. 

(2)  Required  Inputs  to  Operate  MRAS 

MRAS  inputs  are  essentially  the  same  as  those  for  SRAS.  A few 
additional  case  attributes  are  generated  in  PREPRO  especially  for 
multi -resource  cases.  These  include: 

(a)  The  'degree  of  non-parallelism  in  servicing  the  particular 
multi -resource  case,  (y)  . 

(b)  The  proportion  of  time  into  case  completion  the  subsequent 
resources  commence  service,  (A(i)). 

(c)  The  on  scene  time  for  each  need  except  search,  tow  or  escort 
(tos(i))  . 

(d)  The  primary  station  - the  Coast  Guard  station  receiving  the 
distress  call  (as  determined  in  PREPRO) . 

The  user  inputs  remain  the  same  as  in  SRAS,  but  also  include  a switch 
(INTRAP)  to  override  the  preselected  resource  assignment  polic;y.  In  addition, 
the  hand-off  distance  for  tow  (or  escort)  cases  (HO)  must  be  input. 

HO  is  the  minimum  hand-off  distance  from  shore  for  the  tow  (or  escort) 
situation.  The  assumption  is  made  that  hand-offs  occur  at  a distance 
HO  or  greater  from  the  tow  (or  escort  destination) , thus  preventing  the  larger 
resource  from  towing  (or  escorting)  into  waters  not  safe  for  its  navigation. 
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(3)  MRAS  Logic 


When  a case  requires  the  service  of  two  or  more  needs,  the 
OPSIM  EXEC  passes  control  to  MRAS  if  the  case  has  no  long  search 
requirement.  Control  is  also  passed  to  MRAS  from  SASS  if,  at  the 
conclusion  of  the  search,  additional  service  of  more  than  one  need 
is  required.  Additional  notifications  of  this  case  are  created  and 
an  ordered  set  of  capable  resources  are  found  at  each  notification 
time.  Once  this  set  of  capable  resources  has  been  determined, control 
is  passed  to  the  preselected  resource  assignment  policy  (or  the 
redefined  policy,  based  on  the  user's  input  relative  to  the  resource 
selection  in  SRAS  and  the  desired  level  of  station  interaction.)  When 
a resource  has  been  assigned  from  the  set,  (SS)  is  executed  to  simulate 
the  service  of  the  client’s  need.  Pertinent  statistics  relative  to  the 
client  and  the  resource  are  also  calculated  in  SS. 

Figure  14  shows  the  flow  of  operations  for  the  first  steps  of  MRAS, 
i .e. , scheduling  the  set  of  subsequent  notification  times  for  the  needs 
of  a multi -resource  case,  excluding  search,  tow  or  escort.  These  noti- 
fication times  are  the  stimuli  to  the  system  for  assignment  of  resources 
to  serve  this  case's  needs.  Figure  15  illustrates  how  a set  of  capable 
resources  is  determined  and  how  the  user-controlled  switch  selects  the 
proper  resource  assignment  policy  should  certain  station  autonomy  policies 
be  indicated  by  the  user.  These  steps  are  elaborated  in  the  ensuing 
discussion. 

(a)  Scheduling  a Set  of  Notifications  for  a Multi -Resource  Case 

To  simulate  the  dispatch  of  subsequent  resources  to  service  the 
needs  of  a case,  certain  case  attributes  had  to  be  calculated  in 
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Figure  14 

Multi -Resource  Assignment  Subroutine 
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NOTIF 


Figure  15 
NOTIF 


PREPRO  relative  to  the  elapsed  time  of  the  case  and  the  delay  between 
the  arrivals  of  subsequent  resources  to  the  scene  of  the  incident. 

These  attributes  include  the  degree  of  non-parallel  service  of  the 
case,  and  the  delay  of  the  commencement  of  service  on  scene  of  the 
"i"  subsequent  needs,  A(i). 

The  service  of  a typical  multi -resource  case  is  shown  in  Figure  16. 

In  this  situation,  three  needs  require  servicing,  but  none  are  search, 
tow  or  escort.  The  first  resource  is  dispatched  at  t^  and  takes  tvec(l) 
amount  of  time  to  traverse  to  the  scene;  client  is  located  immediately, 
and  service  commences  at  t2«  The  two  additional  resources  arrive  on 
scene  at  times  t^,  and  t^.  The  resources  spend  tos(l),  tos(2)  and  tos(3)  on 
scene,  respectively.  The  elapsed  time,  t0,  that  this  case  is  serviced  on 
scene  is  defined  as  the  time  elapsed  between  t2  and  t^.  When  simulating 
such  a case,  it  is  possible  that  the  service  of  the  (three)  needs  be 
either  in  series  or  in  parallel  or  somewhere  between  these  two  extremes. 

Referring  to  figure  17,  the  range  of  t is  given  by: 

n 

Max  (tos(i)}  < t < £ tos(i), 

where  the  lower  bound  is  strict  parallel  service  and  the  upper  bound  is 
strict  series  service.  The  maximum  number  of  needs  other  than  search, 
tow  or  escort,  is  "n”.  The  calculation  of  t is  made  from  the  following 
equation: 

n 

t = Max  (tos(i)}  + y[E  tos(i)  - Max  (tos(i)}] 
e i 

where , 0 < y <,  i ; 

Note  that  when  y = 0,  the  case  is  served  in  parallel;  conversely,  when 
Y = 1,  the  case  is  served  in  series.  Figure  17  only  suggests  a 
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System  is  notified  case  has  occurred.  Equivalent  to  OCCUR. 
First  resource  arrives  on  scene. 

Second  resource  arrives  on  scene. 

Third  resource  arrives  on  scene. 

First  resource  leaves  scene  after  expending  tos  (1)  amount 
of  time  on  scene. 

Second  resource  leaves  scene  after  expending  tos (2)  amount 
of  time  on  scene. 

Third  resource  leaves  scene  after  expending  tos (3)  amount 
of  time  on  scene. 


tveC(l):  Amount  of  time  the  first  resource  spends  traversing  to  the 


t : 
e 


scene . 

The  elapsed  time  the  client  is  provided  Coast  Guard 
assistance,  on  scene,  but  not  including  search  or  tow. 

Figure  16  . 

Line  Illustration  of  the  Service  of  a Multi -Resource  Case 
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distribution  on  y,of  the  type  which  might  in  the  future  be  used  to  generate 
f by  Monte  Carlo  methods . (This  might  be  appropriate  if  all  other  case 
attributes  were  obtained  via  Monte  Carlo.)  In  the  current  configuration, 
fis  determined  from  the  case  record  in  PREPRO.  (See  the  PREPRO 
discussion.) 

The  parameter  A(i)  insures  that  the  notification  time  to  the  system 
for  need  "i"  occurs  such  that  the  resource  could  expend  its  tos(i) 
within  t . This  A(i)  can  be  viewed  as  the  degree  of  parallelism  among 
the  resources  serving  a multi -resource  case.  Its  range  is  given  by: 

0 < A(i)  <1.  Conceivably,  the  elapsed  time  could  later  be  lengthened 
should  any  of  the  selected  resources  not  be  able  to  arrive  on  scene  within 
the  required  tolerance.  (See  Figure  17  for  an  illustration  of  A(i),  for 
the  general  case.)  Subroutine  SNEED  (see  figure  14) , using  tos  (i) , y 
and  A(i),  calculates  t^,  and  the  set  of  notification  times  (NOTIF(i)} 
for  this  case.  Each  MOTIF (i)  is  given  by: 

NOTIF(i)  = OCCUR  + A(i)  [t  - tos(i)]  -TOL(S) 
where  OCCUR  is  the  notification  time  of  the  case  . OCCUR  will  be  updated 
to  the  time  at  which  the  client  is  found,  should  MRAS  be  entered 
from  SASS.  (The  reader  is  referred  to  the  discussion  in  PREPRO  on  page  59 
for  the  derivation  of  A(i)  from  the  case  record.) 

At  the  notification  times,  i.e.,  each  member  of  the  set  (NOTIF(i) } , 

control  is  passed  to  NOTIF.  N0T1F  finds  a capable  resource  and  selects 
the  proper  RAP. 
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Illustration  of  a Suggested  Distribution  on  y 
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Illustration  of  AQ.)  General  Case;  Figure  17 


t^:  Notification  of  the  case  arrival  to  the  system,  OCCUR. 

Latest  possible  arrival  on  scene  of  first  resource  within 
tolerance,  TOL(S). 

t,:  The  system  is  notified  of  the  requirement  of  service  of  the 

ith  need. 


t,:  Latest  desirable  time  a resource  can  arrive  on  scene  to 

commence  service  of  the  ith  need,  within  tolerance  TOL(S) . 

t^:  Latest  time  a resource  can  arrive  on  scene  to  commence  service, 

t^;  Service  ceases 

Figure  17:  Illustrations  of  - Destribution  and  A(i) 
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If  the  case  is  a multi -resource  tow  or  escort  (a  hand-off  tow 
or  escort)  with  no  previous  needs (other  than  long  duration  search)  , then 
subroutine  NOTIF  is  called  at  OCCUR,  i.e.,  when  the  case  arrives  to  the 
system  or  when  the  client  has  been  found.  For  the  first  resource  assigned 
to  serve  the  tow  need  this  procedure  is  followed.  However,  the  subsequent 
requests  for  resources  to  tow  (or  escort)  are  handled  in  SS,  the  Service 
Subroutine.  A comprehensive  discussion  is  offered  on  this  subject  in  the 
section  describing  SS*  Also,  should  the  case  require  the  service  of  a 
single  tow  or  escort  after  other  heeds  have  been  served,  this,  too,  is 
handled  in  subroutine  SS. 

The  process  for  selecting  a set  of  capable  resources  is  the  same 
as  in  SRAS,  (See  section  3A(3)  of  SRAS  on  page  78  .)  That  is  steps  1,  2, 

3 and  4 of  SRAS  are  executed  for  each  need  triggered  by  each  NOTIF(i). 

Once  an  ordered  set  of  capable  resources  has  been  found,  the  proper 
resource  assignment  policy,  RAP,  is  applied  to  this  set. 

(b)  Selecting  the  Correct  RAP 

The  user  selected  resource  assignment  policy  is  input  relative  to 
the  single  resource  assignment  scheme.  For  simulation  of  multi -resource 
cases,  however,  an  internal  switch  may  be  set  to  allow  adjacent  stations  to 
participate  on  multi -resource  cases,  whereas  station  autonomy  applies 
to  single  unit  cases. 

Referring  to  Figure  15,  with  RAP  4 (P,  PI,  Q)  and  INTRAP  = 1,  the 
computer  redefines  the  RAP  for  multi-resource  cases  to  be  RAP  2 (P,  PI,  A, 
AI , Q) . Similarly,  should  the  user  select  RAP  5 (P,  Q) , then  the  RAP  is 
redefined  as  RAP  6 (P,  A,  Q).  If  RAP  is  1,  2,  3 or  6,  then  the  selected 
RAP  is  executed . 


*See  page  123 
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(c)  Interrupting  the  Service  of  a Multi -Resource  Case 


Should  a resource  serving  a need  of  a multi -resource  case, (other 
than  search,  tow  or  escort,) be  interrupted, that  need  of  the  case  is 
queued.  This  does  not  necessarily  affect  remaining  needs.  However, 
the  client  can  neither  be  towed  nor  escorted  until  all  the  other  needs 
have  been  serviced.  In  other  words,  the  macroscopic  order  of  service 
of  the  case  is  preserved;  that  is,  searching  for  the  client  must  be 
completed  before  any  need  is  serviced;  and  all  the  needs  must  be 
serviced  before  the  client  can  be  towed  or  escorted. 

C.  The  Search,  Assignment  and  Service  Subroutine  (SASS)  of  OPSIM 

(1)  General  Description 

The  approach  to  modeling  long  search  cases  is  quite  different  from 
the  approach  for  serving  other  needs,  for  which  no  consideration  is  given 
to  time  spent  on  scene.  (Usually,  time  on  scene  varies  little  from  one 
resource  to  another  when  servicing  non-search  needs.)  For  search,  how- 
ever, the  time  required  to  search  a given  ’’area"  varies  greatly  with 
resource.  (Note:  search  "area”  will  be  carefully  defined  below.)  The 

primary  objective  when  searching  is  to  select  a resource  which  can 
cover  the  greatest  fraction  of  a specified  search  ’’area”  within  a time 
tolerance  or  before  sunset  and,  if  possible,  at  least  cost. 

The  duration  of  a search  may  be  classified  as  "long"  or  "short", 
and  is  determined  in  PREPRO.  Short  searches* are  simulated  through  SRAS 
or  MRAS,  and  are  generally  exemplified  by  resource  arrival  to  service 
a need  other  than  search,  but  inability  to  locate  the  client  immediately. 
This  often  derives  from  erroneous  position  report  or  drifting  from  the 

*One  half-hour  or  less. 
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reported  position.  In  contrast,  long  searches,  such  as  overdues,  may 
last  as  long  as  a week  or  more  and  may  consume  considerable  resource 
time.  Furthermore,  there  may  be  additional  needs  when  the  client  is 
located . 

It  is  important  to  note  that  the  basic  use  of  SARSIM  is  for  planning 
involving  resource  allocation  and  utilization.  Consequently,  SASS  location 
processes  are  limited,  for  the  objective  is  not  related  to  search 
techniques  and  tactics , Although  future  models  might  perhaps  investigate 
search  tactics,  more  detailed  descriptions  of  cases  would  be  required. 

The  present  data  base  in  inadequate  to  allow  estimates  of  detection 
probability.  For  example,  neither  search  width,  nor  track  spacing,  nor 
search  pattern,  nor  search  area  dimensions  are  given  on  the  assistance  re- 
port. Nonetheless,  it  is  possible  to  extrapolate  the  number  of  linear 
search  miles  for  each  participating  resource  from  the  hours  spent  searching. 
Therefore,  the  term  search  "area"  is  defined  in  terms  of  these  linear 
search  miles.  Given  this  limited  amount  of  data,  the  approach  of  covering 
an  acceptable  portion  of  the  required  linear  search  miles  in  a given 
tolerance  time  (or  prior  to  sunset),  for  a minimum  cost  is  reasonable. 

(2)  Summary  Description  of  SASS 

The  typical  operational  response  to  a need  for  search  is  the 
assignment  of  at  least  one  resource,  regardless  of  time  of  occurrence, 
if  at  all  possible.  This  philosophy  was  incorporated  in  the  modeling  effort. 
Should  the  case  occur  after  sunset,  one  resource  is  sent  to  the  scene, 
if  available.  The  case  is  then  scheduled  for  further  service,  if  necessary, 
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and  resources  are  scheduled  to  arrive  on  scene  at  sunrise  of  the 
following  morning.  This  procedure  is  followed  in  order  to  provide  a 
timely  response  , Keeping  in  mind  that  nighttime  searches  are  generally 
relatively  ineffective,  the  bulk  of  the  search  effort  is  scheduled  for 
daylight  hours.  Should  the  case  occur  between  sunrise  and  sunset  of  a 
given  day,  resources  are  sent  to  search  in  order  to  cover  as  much  of  the 
search  ’'area”  as  possible  before  securing  for  the  night  at  sunset.  The 
search  for  a client  would  then  continue  the  following  day  during  the 
hours  between  sunrise  and  sunset  until  the  total  number  of  search  miles  of 
the  case  are  exhausted  (and  the  client  found,  or  the  search  called  off). 

Endurance  limitations,  either  because  of  refueling  or  crew  change 
requirements,  of  each  resource  type  in  the  inventory  are  taken  into 
account  in  the  assignment  of  the  resources  to  the  case, and  in  scheduling 
subsequent  sorties.  This  is  a user  input  expressed  in  hours  for  each 
resource  type.  (See  Table  ).  Refueling  is  also  scheduled  when 
necessary  and  requires  subsequent  sorties.  The  time  it  takes  to  refuel 
is  also  listed  in  Table  2 . 

The  PREPRO  examines  the  history  of  each  case  in  the  data  base,  in- 
cluding hours  spent  searching,  elapsed  time  of  the  case,  and  the  search 
speed  of  the  resource  that  responded  to  the  case,  to  develop  the  equiva- 
lent number  of  resources (operating  in  parallel  )that  participated  in  the 
search  (S-^) , and  the  total  linear  miles  covered  in  the  search  (TSM) . 

Since  it  is  operationally  desirable  to  assign  an  aircraft/surface 
resource  mix  to  a search  case,  the  total  linear  miles  are  allocated  to 
the  resources  assigned  to  the  case.  This  allocation  or  fractional  split 
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FUEL 

TIME 

ENDURANCE 

REFUEL 

RESOURCE  TYPE 

(HRS.) 

(HRS.) 

UTB(L) 

14 

0.5 

UTB(M) 

14 

0.5 

UTB(U) 

5 

0.3 

MLB(44-52) 

14 

0.5 

MLB  36 

14 

0.5 

MRB/MSB 

14 

0.5 

WPB  95 

120 

1 

WPB 

82 

1 

WYTM/WYTL 

120 

1 

WMEC 

UNL+ 

8 

WHEC 

UNL+ 

8 

C-130 

12* * 

0.5 

HU16E 

12* 

0.5 

HH52A 

4.5 

0.3 

HH3F 

6.0 

0.3 

+999  Hours 

* Assumes  Double  Crew 


TABLE 

Fuel  Endurance  and  Refuel  Time  (Hrs.) 
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is  a user  input,  the  only  requirement  being  that  the  fractions  must 
add  to  unity.  To  demonstrate  this  concept,  consider  a case  requiring 
two  search  resources . Hie  user  input  for  the  split  between  two  search 
resources  could  be,  for  example,  0.70  and  0.30.  Using  the  assignment 
criteria,  most  likely  an  aircraft  would  be  assigned  to  cover  0.70  of 
the  total  miles  while  a surface  resource  has  a good  probability  of  being 
assigned  the  remainder,  0.30.  Recall  that  the  assignment  criterion 
is  based  on  the  least  expensive  resource  that  will  cover  an  acceptable 
fraction  of  the  desired  amount  of  search  "area”  within  tolerance  or 
before  sunset. 

One  additional  user  input  helps  to  control  the  intensity  and  duration 
of  the  search  by  allowing  the  user  to  place  emphasis  on  any  desired  day 
of  the  search.  (For  example , the  user  may  choose  to  emphasize  the  first 
day.)  This  input  variable  is  PDC(DAY) . It  may  be  desirable  to  attempt 
to  cover,  for  example,  at  least  501  of  the  search  miles  on  the  first 
day  and  at  least  20%  of  the  remaining  search  miles  on  subsequent  days. 

This  example  models  an  initial  concerted  search  effort  followed  by  a 
decreased  emphasis  on  subsequent  days. 

(3)  Inputs  to  Operate  SASS 

(a)  The  additional  case  attributes,  other  than  those  discussed  in 
SRAS  but  required  by  SASS, include  the  following:  (These  attributes  are 


developed  in  PREPRO) . 

(i) 

TSM: 

Total 

(linear) search  miles  on  the  case. 

(ii) 

sr 

Total 

number  of  search  resources  required  on  the  case 

(iii) 

n: 

The  number  of  needs  except  search,  tow  or  escort. 
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(iv) 

m: 

The  number  of  sequential  tows  or  escorts  required 

(v) 

P: 

Primary  station  of  the  case. 

(vi) : 

S: 

Severity  level  of  the  case. 

(vii) 

XC, 

YC 

Case  location. 

(b)  The  additional  user  inputs  include: 


(i) 


(ii) 


SUNSET  and  SUNRISE  times  (Seasonal  variations 
can  be  introduced  by  exercising  either  a peak 
or  non -peak  scenario.) 

(TOLS(S):  Tolerance  times  for  searching  as  a function 
of  severity  level,  S,  of  the  case. 

(iii)  SOA^(L):  Search  speed  of  the  Lth  type  resource. 

(iv)  END(L):  Endurance  (hours)  of  Lth  type  resource. 

Time  it  takes  the  Lth  resource  to  refuel. 
Operating  cost/hour  for  the  Lth  type  resource. 

(vii)  PDC  (DAY) : Desired  percentage  of  the  search  miles  to  be 
covered  by  each  search  resource  as  a function 
of  the  DAY  of  the  search. 

(viii)  PRTSM(i) : Fractional  split  of  TSM  among  the  S£,  search 
resources  assigned  to  the  case,  (i=l,  2,  ..., 


(v)  t£(L) 

(vi)  OC(L) 


(ix)  x:  The  number  of  hours  before  SUNRISE  when  an 

attempt  is  made  to  assign  resources  to  search 
cases  secured  the  night  before. 

(x)  INTRAP:  INTemal  (adjacent  inclusive)  Resource 

Assignment  Policy  switch. 
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(4)  SASS  Logic 


SASS  is  called  by  the  OPSIM  EXEC  if  S^,  the  number  of  resources 
on  a long  search  case,  is  at  least  one.  Any  other  subsequent  need 
requirements  are  later  served  through  SRAS  and  MRAS , depending  on  the 
values  of  n and  m. 

The  first  step  in  SASS  is  to  allocate  to  each  resource  that 
portion  of  the  total  search  miles,  TSM,  indicated  by  the  values  of 
PRISM (i)  . (See  Figure  18.)  The  result  is  a set(SM(i)}  of  search  miles 
allotted  to  each  resource.  Table  3 below  illustrates  how  the  user  may 
define  the  fractional  split  of  these  miles  as  a function  of  the  value  of 
S^,  the  number  of  search  resources.  The  set  {SM(i)>  is  given  by: 

SM(i)  = TSM  * PRTSM(i)  , where  i = 1(1)  Sr 

OCCUR,  the  time  the  case  enters  the  system,  is  examined  next. 
Should  the  case  take  place  during  the  hours  between  SUNRISE  minus 
x hours  and  SUNSET  of  a given  day,  SASS1  is  called  after  notifications 
have  been  created  for  each  SM(i) . Creating  additional  notifications 
to  the  system  treats  the  case  as  a set  of  single  resource  cases,  each 
having  a requirement  for  covering  SM(i)  search  miles.  Should  the  case 
enter  the  system  sometime  after  SUNSET,  but  prior  to  SUNRISE  minus 
x hours,  then  a single  resource,  if  available,  is  vectored  to  the 
scene  immediately.  The  remaining  S^-l  required  SM(i)  *s  are  placed 
in  a SUNRISE  LIST,  via  RISE,  to  be  served  at  SUNRISE  minus  x hours. 

In  order  to  model  the  concerted  effort  approach  to  cases  occurring  at 
night,  the  values  PRTSM(i)  should  be  input  in  descending  order 
of  magnitude. 


-107- 


Figure  18 

SASS  Flowchart;  RISE 
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PRTSM(i) 


Slv\ 

1 

2 

3 

4 

5 
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1.00 

- 

- 

- 

- 

2 

.70 

.30 

- 

- 

- 

3 

.50 

.30 

.20 

- 

- 

4 

.30 

.30  | 

.20 

.20 

5 I 

.30 

.25  1 

.20 

.15 

.10 

Table  3 

Fractions  of  PRTSM(i)  for  varying  levels  of  S-^ . 

SASS1  finds  an  ordered  set  of  capable  resources  at  the  primary 
and  adjacent  stations  and  uses  setps  1 and  2 of  SRAS.  (See  Figure  19.) 

An  attempt  is  made  to  complete  the  search  miles,  SM(i), within  search  tol- 
erance time,  TOLS(S),  or  before  SUNSET  for  long  search  cases.  Comparing  the 
current  simulation  clock  time,  TIME,  plus  TOLS(S)  to  SUNSET  defines  the  amount 
of  time  available  to  search  before  securing  for  the  night  at  SUNSET.  This 
applies  to  aircraft  only,  as  surface  resources  are  permitted  to  search  at 
night  to  their  endurance  limits.  Each  resource  type  has  some  capability  to 
search;  whether  they  are  all  capable  to  serve  this  particular  case  depends 
on  the  environmental  conditions . The  appropriateness  of  selecting  a 
resource  is  also  a function  of  each  one's  ability  to  cover  an  "area" 
satisfactorily.  For  each  of  the  K capable  resources,  PR(k)  is  calculated 
to  represent  the  percentage  of  the  "area"  which  that  resource  can  cover  within 
TOLS(S),  or  before  sunset.  This  is  a function  of  the  position  of  each 
resource  relative  to  the  case,  the  vector  and  search  speeds  of  each  resource 
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Figure  19 
SASS1  Flowchart 
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and  the  endurance  and  refuel  times  of  each  capable  resource.  The  cal- 
culation of  PR 00  is  best  illustrated  by  referring  to  Figure  20. 

Consider  two  capable  resources,  the  kth  and  (k+1) , which  can  start 
for  the  search  area  at  some  simulation  clock  time,  TIME.  The  kth  resource 
which  has  a shorter  endurance  than  the  (k+l)st,  arrives  at  the  search  area  at 

time  U after  expending  t (k)  to  arrive  on  scene.*  It  must  depart  the  area 
1 r vec 

at  tg  to  return  home  and  spend  t^(L)  amount  of  time  refueling,  then  takes 

t (k)  amount  of  time  to  return  to  the  search  area,  arriving  at  t.  to  con- 
vec v ^ 

tinue  searching.  The  slope  of  the  straight  lines  between  and  t^,  and 
between  and  t5,  S0A3(L)/SM(i) , is  the  normalized  rate  of  coverage  for 
this  resource,  where  SOA^CL)  is  the  search  speed.  PR(k)  is  the  product 
of  this  rate  and  the  accumulated  time  spent  searching.  The  (k+l)st 
resource  arrives  on  scene  at  and  searches  until  t5,  covering  PR(k+l) . 

Both  resources  stop  searching  at  TIME  + TOLS(S). 

Once  the  set  of  PR(k) 's  is  calculated,  the  desired  coverage  level, 
is  retrieved.  For  those  short  search  cases  which  require  an  additional 
resource  to  search(i.e.,  S2  = 2) ,SASS1  is  called  with  PDC(DAY)  = 100%,  and 
DAY  equal  one  (since  it  is  desirable  to  cover  the  entire  search  area 
that  first  day  before  serving  any  additional  need  on  these  short 
search  cases).  Also,  the  severity  of  the  case  may  be  increased 
(as  specified  by  the  user)  in  this  case  to  the 

*It  is  assumed  here  that  in  the  typical  operational  situation  the 
searching  resource  is  dispatched  from  its  home  station,  rather  than  from 
whatever  location  happens  to  obtain  at  that  moment.  Little  accuracy 
is  lost  in  the  calculation  of  PR(k)  as  a result  of  this  assumption. 
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For  any  capable  resource  R,  the  percentage  area  covered,  PR(R) , 
is  given  by  the  following  equation: 


PR(R)  - ) (END(L)  - 2tvecW}  1^]%^ 


+ TOLSCS)  - {ENB(L)  + tf(L)  j 


•t  (k) 
vec  J 


(Note:  Figure  20  is  continued  on  the  following  page) 
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I TOLS  (J 
END (L) +1 


where,  I TOLS(S) 


represents  the  largest  number  possible  integral  of 


sorties  (during  TOLS(S)  the  resource  expends  a maximum  amount  of  time, 
subject  to  its  endurance  limitations);  and,  the  following 
conditions  hold: 


A. 

(END(L) 

- 2 t (k)}  > 0 
vec 

B. 

TOLS  (S) 

- (END(L)  + tf  (L) } 

C. 

(END(L) 

- 2t  (k) } 
vecv  J 

TOLS(S) 
END(L)+t~(L) 


■‘vec®  i 0 


> TOLS  (S)  - { END  (L)  +t£  (L)  } 


' tvec(k) 


TOLS (S) 


END(L)+tf(L) 


D.  PR (k)  > 0 

In  addition,  certain  situations  can  occur,  and  PR(k)  takes  on  other 
forms.  These  are: 


A.  If  (END(L)  - 2 tyec(k)}  < 0,  then  PR(k)  = 0 

n Tf  micro  - +*  n.yy  [ 1 TOLS(S)  1 

r*  [END(L)  + t (LJJ 

[END (L)  - 2t  K CRD ) 
vec 

C.  If,  TOLS(S)  - (END(L)  + tr(L) }|T0LS(S) 

1 END  CL)  +tf(L) 

{END(L)  - 2 tvec(k)} 


t (k)  < 0, 
vec  ^ J 


- t 


then  TOLS(S)  - (END(L)  + tf(L)} 


TOLS(S) 
END(L)+tf(L) 


vec 


■t  (k)  = 
vecv  J 


(END(L)  - 2tv0c(k)} 


and  PRQc)  - ^30!  (END(L)  - 2tvec(k)  j g^tf(L)  * 1 


Figure  20  (continued) 
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value  SVAR  to  ensure  quick  response  and  non-interruptibility  of  this 
additional  resource.  The  cost,  C(W,  &r  each  capable  resource  is 

calculated  using  the  following  equation. 

C(X)  = OCCL)*(tvec(l0  + SM(i)/SOA3(L)) 

Cost  as  calculated  here  includes  the  total  tine  spent  searching  and 
the  cost  to  vector  to  the  scene. 

Those  resources  whose  PR(k)  meet  the  desired  PDC(DAY)  are  ranked 
on  increasing  cost.  Those  resources  whose  PR (10  is  less  than  the 
desired  are  ran'Kec^  on  decreasing  PR 00  . Finally, 

those  resources  which  cannot  cover  any  area  before  TOLS(S),  but 
can  at  least  vector  to  the  search  area  and  return  within  endurance, 
are  ranked  in  increasing  tyec(k).  The  cost  for  any  additional  sorties 
required  because  of  limited  endurance  is  not  directly  calculated 
here,  because  these  resources  are  already  penalized  in  the  PR(k)  cal- 

culations . 

A final  merged  list  is  created  listing  ranked  capable  resources 

first  by  increasing  cost,  next  by  decreasing  PR(k),and  last  by  increasing 

t (10  (See  Figure  21.)  Control  is  passed  to  RAP  to  find  a re- 
vecv 

source  at  the  primary  (and  adjacent)  stations (s)  to  service  the  case 
from  this  list.  (The  internal  switch  INTRAP  is  activated  as  in  MRAS 
should  the  selected  resource  assignment  policy  be  RAP  4 or  RAP  5 .) 

SSS,  the  Search  Service  Subroutine  is  called  once  the  capable 
resource  is  found  in  RAP.  Within  SSS,  if  this  is  the  first  resour 
assigned  to  the  case,(i.e.  ,SFLAG  is  unity) , control  is  passed  to  TEST. 

The  objective  is  to  vector  the  first  resource  immediately  to  the  scene 
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© 


Calculate  C(k)  = OC(L)*  CtvecCk)  * 


(PR(k) )=0) A (END(L)  -2tvec(k>0)  /PRCk^PI 


(PR(k)>0)A(PR(k)<PDC(DAY) 


CPR(k) >0) A (PR(k) >PDC(DAY) ) 


1 f 

- — , * — — 

Rank  resources  on 
increasing  t (k) 

1 

Rank  resources  on 
increasing  cost 

1 

Rank  on  de- 
creasing PR(k)  | 

^RGE/ 

LISTS 


Set 

RAP  = 2 


< Resource  Assignment 

Policy  _J 


t,_(k):  ^SWSET-TJME-^4--  ^ARSffl 


vec 


t (k) 
vecv  ' 


■Is  resource 

selected  °©>-  — % 

aircraft?  @TIME+t  (k) 
^ vec 


CRSG 

v_/ 


Yes 


TIME  + t (k):  SUNRISE ^MSCH 

sYec  ^ (aTTME  + 


Figure  21 

SASS  and  SASS1  Cont'd 
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TEST 


J 


@TIME  + t 


vec 


rv'i  + SM(i) 

w S0A3(L) 


/T\ 

{J  COMPL  J 

XU 


Aircraft 


C ) 


Figure  22 
TEST  and  ARSCH 
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SM(i)  = SM(i) 
ts(i)*SOA3(L) 


C SD 

I 


? 

Examines  the  SUNRISE  j 
LIST  and  vectors  re- 
sources to  arrive  at 
SUNRISE  when  possible 
| or  thereafter 


i 

Places  queued 
search  cases  in 
SUNRISE  LIST 


.jzzs-zz  z zzz ...  _ 


XRISE  is  called  at  TIME  = SUNRISE 
XSET  is  called  at  TIME  = SUNSET 


i 

i 


i 

i 
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I 

> 

i 
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i 

-x 


DESTROY 

CASE 


Release  the  resource; 
Search  completed 


Release  the 
resource;  destroy 
SM(i) 


Figure  23 

NSET;  XRISE ; XSET;  and  COMPL 


*See  SS  routine 


w 


to  commence  searching  for  the  client,  (See  Figures  21  and  22.)  TEST 
compares  the  endurance,  END(L) , against  the  total  time  required  on  the 
case,(i.e,,  to  vector  to  and  from  the  scene,  2 t c(k);  plus  the 


source  is  sent  to  the  scene  and  control  is  passed  to  event  routine  COMPL 
at  the  end  of  service  of  the  case.  It  is  assumed  that  the  longer  en- 
durance resources  will  remain  on  scene  searching  during  the  night.  COMPL 
(see  Figure  23)passes  control  to  TERM  and  subsequently  to  EXQ.  TERM 
terminates  the  search  need  of  the  case  just  served,  while  EXQ  examines 
the  queue  for  a case  or  a need  of  a case  that  can  be  serviced  by  the 
resource  which  just  became  idle  (i. e.,  completed  serving  the  search  need)  _ 
(See  the  following  section  on  SS  for  discussions  of  TERM  and  EXQ.)  COMPL 
also  examines  the  case  to  determine  if  any  subsequent  needs  beyond  search 
require  service.  Control  is  passed  to  SRAS  or  MRAS  dependent  on  the  values 
of  n and  m. 

If, on  the  other  hand,  the  first  selected  resource's  endurance  is 
less  than  the  total  expected  time  required  to  spend  searching,  then 
control  is  passed  to  ARSCH,  at  the  time  the  resource  arrives  on  scene 
to  commence  search.  (See  Figure  22.) 

The  subroutine  ARSGT  schedules  the  completion  of  the  search  need  or 
additional  sorties  (if  refueling  is  required  to  complete  the  service 
of  the  case) ; updates  the  SM(i)  to  be  covered;  and  secures  the  case  for 
the  night,  if  necessary.  To  model  the  search  capability  of  certain 
resources  more  realistically,  aircraft  are  prevented  from  continuing 


. If  END(L)  compares  favorably,  then  the  re- 


-118- 


their  searching  after  sunset,  whereas  surface  resources  are  permitted 
to  continue  to  search  beyond  sunset,  but  within  their  endurance  con- 
straints. 

If  the  selected  resource  is  an  aircraft  and  the  required  search 
time,  t2 Ci)  ? can  be  expended  within  endurance  and  vector  time  limitations 
and  prior  to  SUNSET,  then  COMPL  is  called  at  the  end  of  the  search  time. 

If  instead,  SUNSET  occurs  before  the  aircraft  can  fulfill  its  ts(i),  the 
search  is  secured  for  the  night,  and  the  t (i)  is  updated  to  the  amount 
of  time  remaining  until  SUNSET.  Since  this  search  need  has  not  been  ful- 
filled, control  is  passed  to  NSET  at  SUNSET.  NSET  updates  the  remaining 
search  miles  SM(i) , places  the  need  in  the  SUNRISE  LIST  via  subroutine 
RISE,  and  calls  EXQ.  The  SUNRISE  LIST  is  examined  at  SUNRISE-X  hours. 
Surface  resources  remain  on  scene  covering  their  assigned  SM(i)  if  the 
endurance  limitations  have  not  been  exceeded.  Upon  completion  of  t (i) 
COMPL  is  called. 

In  the  instance  where  the  selected  resource  cannot  cover  its  assigned 
SM(i)  within  endurance,  sorties  are  scheduled  to  complete  the  search  need. 
The  resource  can  only  search  that  amount  of  time  representing  the 
difference  between  the  endurance  and  the  time  to  vector  to  and  from  the 
scene.  This  time  becomes  t (i)  in  this  instance.  Surface  resources  remain 
on  scene  (beyond  SUNSET  if  necessary)  expending  their  assigned  ts(i), 
returning  home  to  refuel . Aircraft  will  remain  on  scene  and  search  until 
SUNSET  or  until  they  have  spent  their  ts(i),  whichever  occurs  first. 

In  the  latter  case,  if  SUNSET  occurs  first,  then  NSET  is  called.  If  re- 
fueling is  required  to  continue  service  of  this  case,  prior  to  SUNSET, 
then  control  is  passed  to  FUEL. 
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The  number  of  search  miles  SM(i)  are  updated  in  RJEL  and  control 
is  passed  to  HOMEF,  where  the  resource  is  refueled.  The  resource  be- 
comes available  to  be  vectored  back  to  the  search  "area"  after  expending 
t^(L)  time  refueling.  HOMEF  passes  control  to  SNDBK.  Subroutine  SNDBK 
first  attempts  to  find  a "better"  idle  capable  resource  to  fulfill  the 
remaining  search  requirement.  This  is  done  with  a call  to  SASS1.  If 
no  resource  can  be  found  , then  the  original  resource  is  assigned  to 
continue  searching. 

In  Subroutine  SNDBK, a resource  will  be  vectored  back  to  the  search 
area  if  he  can  arrive  prior  to  SUNSET  of  that  day,  or  if  his  vector 
time  is  so  large  that  the  resource  will  arrive  on  scene  after  SUNRISE 
minus  X hours  of  the  next  day.  Should  the  resource  not  be  able  to  arrive 
before  SUNSET,  but  can  arrive  at  SUNRISE  minus  X hours  or  after,  then  the 
search  need  is  placed  in  the  SUNRISE  LIST  via  RISE.  (See  Figure  24 
illustrations  of  FUEL,  HOMEF,  and  SNDBK.) 

The  discussion  relative  to  SSS  thus  far  has  covered  the  first 
resource  assigned  to  a case,  and  the  scheduling  of  subsequent  sorties 
for  any  resource  selected  to  serve  a search  need  of  the  case.  Referring 
back  to  Figure  21,  if  this  resource  is  not  the  first  one  on  the  case 
but  is  a surface  resource,  then  control  is  passed  to  ARSCH  when  the 
resource  arrives  at  the  search  area.  If ^however,  the  resource  is  an  aircraft, 
then  it  is  vectored  to  the  case  if  it  can  arrive  on  scene  prior  to 
SUNSET  or  if  the  vector  time,  t (k)  is  so  long  that  the  resource  will 
not  arrive  until  after  SUNRISE  of  the  next  day.  Should  the  aircraft 
not  be  able  to  arrive  before  SUNSET,  but  can  arrive  prior  to  SUNRISE  of  the 
next  day,  the  case  is  placed  in  the  SUNRISE  LIST  via  RISE,  and  EXQ  is  called. 
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Figure  24 

TEST;  ARSCH;  FUEL;  HQMEF;  and  SNDBK 
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SUNSET- 


@TIME  + tyec(k) 


SUNRISE  -x  @TIWE  + tvec(k) 


ARSCH 


Figure  24  [continued) 
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The  event  XSET  is  called  automatically  at  SUNSET.  It  has  been 
created  to  specially  handle  queued  search  cases.  XSET  extracts  search 
cases  from  the  queue  and  places  them  in  the  SUNRISE  LIST. 

XRISE  examines  the  SUNRISE  LIST  at  SUNRISE  minus  X hours  and 
vectors  resources  at  appropriate  times  to  arrive  on  scene  at  SUNRISE. 

These  routines  are  illustrated  in  Figure  23. 

D.  The  Service  Subroutine  (SS)  for  SRAS  and  MRAS  of  OPSIM 

(1)  General  Description 

Once  a resource  has  been  selected  to  service  a need  in  either  SRAS 
or  MRAS,  control  is  passed  to  the  Service  Subroutine,  SS.  This  routine  ' 
simulates  the  required  service  activities;  the  continuous  coverage  of  the 
client,  should  it  be  required  in  a multi -resource  case;  the  re-evaluation 
of  the  severity  level  of  the  case  during  the  elapsed  service  time,  etc. 

Upon  completion  of  the  service  of  a need  of  a case,  the  resource 
assumes  an  idle  (alpha)  status.  The  case  statistics  relative  to  servicing 
this  need  and  the  statistics  regarding  the  utilization  of  the  resource 
are  recorded.  The  queue  is  examined  for  waiting  cases  at  the  resource’s 
primary  and  adjacent  stations,  depending  on  the  selected  resource 
assignment  policy,  to  determine  if  the  released  resource  is  capable  of 
serving  a waiting  case  before  returning  to  home  port. 

(2)  Inputs 

The  operation  of  SS  is  dependent  on  the  case  attributes  and  the 
user  inputs.  Certain  simulation-developed  case  attributes  are,  of 
course,  carried  for  statistical  analysis  purposes. 
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(a)  Case  Attributes 


The  Case  attributes  used  in  SS  include: 


(i) 

tos(i) : 

The  time  on  scene  for  the  l need. 

(ii) 

n: 

The  number  of  needs  other  than  search  or  tow. 

(iii) 

m: 

The  number  of  tow  or  escort  resources. 

(iv) 

S2: 

The  indicator  for  a short  search  requirement. 

(v) 

TSM: 

The  miles  to  be  covered  searching  for  the  client 
(also  required  for  a short  search) . 

(vi) 

S: 

Severity  level  of  the  case. 

(vii) 

NEED: 

Explicit  need  of  a case  undergoing  service. 

These  attributes  were  discussed  in  the  section  on  PREPRO. 

(b)  User  Inputs 

The  user  inputs  are  a combination  of  operational  experience  and 
extrapolation  of  historical  data: 

(i)  DRS(j):  Probability  distribution  for  re-evaluation  of 

the  case  severity  level,  i.e.,  the  severity  level 
becomes  S + IPC,  where  DRS(l):  % Increase  by  a 
unit,  IPC  = 01;  and  DRS(3):  % No  change,  IPC  = 0. 

(ii)  KS:  The  number  of  examinations,  on  scene,  of  the 

case  severity. 

(iii)  HU:  Distribution  for  hook-up  time  tor  tow  cases 

(or  delay  for  surface  escort  cases) . 

(The  time  required  to  obtain  the  information  required  in  the  SAR 
assistance  form  is  not  specifically  included  in  the  service  time, 
nor  is  there  an  allowance  for  any  delay  for  "unhook"  time.  In 
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most  instances  these  activities  require  a relatively  minor  fraction 
fraction  of  the  total  service  time  of  the  case.) 

(iv)  HO:  Hand-off  point,  (miles  from  shore)  for  multi - 

resource  tows , or  escorts . 

(3)  SS  Logic 

Control  is  passed  to  SS  after  the  assignment  of  a resource  (to 
serve  the  itn  need  of  a case)  is  made  in  RAP.  ARVSN  is  called  at  the 
time  the  assigned  resource  arrives  on  scene  or  at  the  expected  location 
of  the  client. 

ARVSN  performs  a number  of  functions  which  include:  passing  control 

to  SRCHF,  a subroutine  which  simulates  the  activities  for  locating  the 
client  under  short  search  conditions;  calling  ONSCN,  a subroutine  which 
simulates  the  re-evaluation  of  the  cases  severity  level  as  time  passes 
during  the  servicing  of  a need;  and  releasing  a resource  which  serviced 
a previous  need  and  had  covered  the  client  until  another  resource  could 
arrive  on  scene.  RETN  is  called  when  coverage  is  no  longer  required. 

(See  Figures  25-27.) 

If  the  case  is  a multi -resource  case,  coverage  is  provided  for  the 
client  unless  the  covering  resource  is  interrupted  to  serve  a higher 
priority  case.  Therefore,  upon  arrival  on  scene,  should  a resource  be  on 
scene  and  waiting,  after  having  served  a need  of  this  case,  the  waiting 
resource  is  released.  This  is  done  in  RETN.  (See  Figure  27.)  TERM  and 
EXQ,  called  by  RETN,  record  statistics  on  the  case  and  resource,  and 
examine  the  queue  to  serve  waiting  cases,  respectively.  These  routines 
are  explained  later  in  the  discussion. 
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SR:  Single  Resource 

MR:  Multi -Resource 


Figure  27 
ONSCN  and  RETN 
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SRCHF  is  called  if  a short  search  is  required  only  on  the  service 
of  the  first  need.  An  attempt  is  made  here  to  simulate  the  typical 
situation  where  a resource  has  been  vectored  to  the  expected  location, 
but  cannot  find  the  client.  The  position  may  have  been  erroneously 
reported,  or  the  client  may  have  drifted  from  his  last  reported  position. 
The  resource  must  search  for  the  client  or  call  up  an  additional  re- 
source to  perfonn  the  search.  (See  Figure  28.) 

Before  a client  can  be  towed  (or  escorted) , his  destination  must  be 
established.  Ordinarily  the  client’s  destination  is  the  primary  station 
(i.e.,  the  case's  primary  station).  However,  in  the  situation  where 
the  client  is  being  towed  (or  escorted)  by  a resource  on  patrol , then 
the  client  is  towed  to  a predesignated  station  for  that  patrol  re- 
source % (Each  patrol  resource's  predesignated  station  is  treated 
as  an  adjacent  to  the  patrol  station,  where  the  patrol  station 
is  considered  a primary.  Each  patrol  station  will  have  on  adjacent.) 

Once  the  destination  is  known,  the  distance  to  that  point,  DD,  is 
calculated. 

Analysis  of  the  historical  data  indicated  that  very  few  tow  or 
escort  cases  required  more  than  a single  hand-off,  implying  that,  in 
most  cases,  not  more  than  two  resources  towed,  or  escorted,  in  series. 

The  decision  was  therefore  made  to  limit  the  maximum  number  of  hand-offs 
to  one,  or  the  case  will  have  a maximum  of  two  tow  needs  (or  two 
escort  needs) . (Cases  involving  more  than  one  resource  to  tow  or 
escort  will  automatically  be  reduced  to  two  resources.)  The  request 
for  tow  or  escort  is  made  at  the  arrival  of  the  case  to  the  system,  or 
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Figure  28:  SRCHF,  EXQ;  TERM  and  HOME 


-130- 


at  the  completion  of  those  needs  other  than  tow  or  escort.  The  request 
for  hand-off  is  made  after  the  first  tow  or  escort  is  satisfied.  These 
requests  are  not  scheduled  in  advance  as  in  the  situation  of  servicing 
the  other  needs. 

If  the  case  is  a single  resource  air  escort  (i.e. , the  escorting 

resource  is  an  aircraft),  the  time  spent  escorting,  TOWTIME (i),  becomes 

the  ratio  of  DH,  the  distance  between  the  client  and  his  destination, 

th 

to  the  speed  of  advance  of  the  l type  resource  assigned  to  this  need 
of  the  case;  either  S0A1(L)  or  S0A2(L),  depending  on  weather  conditions 
1 or  2. 

If,  instead,  the  case  indicates  a single  resource  tow  (or  surface 
escort),  (i.e., the  escorting  or  towing  resource  is  a surface  unit) 
then  the  time  expended  in  rendering  service  includes  the  hook-up  time, 
t^,  and  the  tow  or  escort  time,  TOWTEME(i)  taken  as  the  ratio  of  the 
distance  DD  to  the  towing  speed,  TSP.  The  towing  speed  is  dependent  on 
the  client  length.  The  hook-up  time,  t^,  is  drawn  randomly  from 
the  distribution  HU,  a user  input.  Surface  escorts  have  been  approximated 
by  treating  them  as  tow  cases.  Historically,  their  number  is  not 
excessive  and  thus  the  approximation  is  acceptable. 

If  the  case  requires  a hand-off  tow  or  escort,  then  the  distance  to 
the  destination  is  divided  evenly  between  the  two  needs.  The  hand-off 
point  is  a point  halfway  between  the  client  and  his  destination. 

However , should  half  of  the  distance  between  the  client  and  his  des- 
tination, D2(CASE),  be  less  than  HO  miles,  where  TO  is  a user  input 
representing  the  minimum  hand-off  distance  from  the  client’s  destination, 
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then  the  hand-off  point  becomes  HO  miles  from  the  client’s  destination. 
The  distance  off-shore  is  also  updated  relative  to  this  hand-off  point 
for  the  second  tow  or  escort  need.  HO  is  currently  considered  as  a 
quarter  mile  off-shore. 

The  time  spent  towing  the  client  to  the  hand-off  point  is  calculated 
similarly  as  in  the  single  resource  case.  Once  the  hand-off  point  has 
been  reached,  or  the  single -resource  tow  has  been  completed,  control  is 
passed  to  RETN. 

Should  a tow  or  surface  escort  be  interrupted  by  a higher  priority 
case,  the  client's  position  is  updated  to  where  he  is  dropped  off,  and 
the  need  queued.  The  hand-off  point  is  "preserved"  in  the  case  of  an 
interrupt  of  a multi-resource  tow.  No  provision  is  made  for  picking 
up  air  escort  cases  if  the  escorting  resource  is  interrupted  to  serve 
a higher  priority  case. 

A means  of  re-evaluating  the  severity  level  of  the  case  has  been 
provided  to  the  user  in  the  subroutine  ONSCN . From  the  cumulative  dis- 
tribution of  DRS,  the  direction  of  change  in  severity  is  determined  by 
the  Monte  Carlo  of  the  amount  of  unit  change,  IPC.  In  specifying  the 
parameter  KS,th.e  user  indicates  that  the  severity  is  to  be  re-evaluated 
KS-1  times  during  the  service  of  this  need.  RETN  is  called  at  the  end  of 
service  of  the  need  of  the  case.  Since  the  case's  severity  level  is 
expected  to  remain  fairly  constant  during  the  service  of  the  tow  or 
escort  need,  no  re-evaluation  is  provided  when  these  needs  are  being 
serviced. 
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RETN  insures  continuous  coverage  of  the  case  should  the  service 
of  the  case  not  be  completed  and  the  subsequently  scheduled  resources 
have  not  arrived  on  scene.  (See  Figure  27.)  The  resource  already  on 
scene  will  provide  coverage  for  the  client,  but  cannot  insure  coverage 
should  a higher  priority  case  arrive  to  the  system  and  require  the 
services  of  the  covering  resource.  If  a resource  has  arrived  to  serve 
another  need  of  the  case,  and  thus  covers  the  case, or  if  the  case  is  single 
resourced,  then  TERM  is  called,  followed  by  EXQ  and  the  covering  resource 
is  released.  Before  a resource  covers  a client,  it  examines  the  queue 
to  see  if  it  can  serve  a need  of  this  case  that  has  been  previously 
queued.  In  addition,  a covering  resource  examines  the  queue  for  a queued 
need  of  any  case,  every  QT  hours,  where  QT  is  variable. 

Figure  27  illustrates  RETN  where  coverage  is  provided  dependent  on  the 
relationships  of  the  arrive -on -scene  time  ROS(i  + 1)  of  the  (i  + l)s  at 
resource  to  the  leave-scene  time,  RLS(i),  of  the  i^h  resource. 

Besides  providing  coverage  to  the  client  during  the  service  of  his 
needs,  the  resource  serving  the  last  need  will  serve  the  tow  or  escort 
needs  if  capable.  If  not,  that  resource  will  cover  until  resource 
capable  of  towing  can  arrive  to  scene. 

As  mentioned  previously,  short  searches  are  handled  in  SRCHF  if 
the  search  is  done  by  either  the  first  resource  on  scene  or  by  an 
additional  resource  called  to  scene.  (See  Figure  28.) 

SRCHF  examines  the  S^  code  of  the  case  and  either  lengthens  the 
resource  service  time  of  the  first  resource  on  scene,  so  that  a search 
can  be  accomplished;  or  passes  control  to  SASS1,  a part  of  the  Search, 
Assignment  and  Service  Subroutine,  SASS.  Resource  selection  is  made 
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in  SASS1  to  cover  the  total  search  miles,  TSM,  the  first  day.  The 
severity  level  of  the  case  is  increased  in  order  to  model  the  urgency 
of  the  request  for  service  made  by  the  first  resource  on  scene,  and  also 
to  lower  the  probability  that  this  additional  resource  can  be  interrupted. 

If  the  search  is  done  by  the  resource  serving  the  first  need,  its 
on  scene  time,  tos(i),  is  lengthened  by  the  amount  t^.  This  can  occur 
either  directly  through  examination  of  the  value  of  or  by  default, 
should  there  be  no  additional  capable  resource  available  when  requested 
by  the  first  resource  on  scene.  In  this  case,  the  resource  serving  the 
first  need  will  also  perform  the  search. 

The  philosophy  behind  SRCHF  is  that  the  resource  assigned  to  the 
first  need  was  selected  with  regard  to  this  need  ,not  for  searching.  Only 
after  arrival  on  scene  to  find  the  client  missing  did  the  "need"  for 
search  become  apparent.  Thus,  as  is  often  the  case,  another,  more 
suitable  resource  may  be  required  to  find  the  client. 

Upon  completion  of  service  of  all  needs,  TERM  records  certain  of 
the  case's  statistics,  removes  the  case  from  the  system  and  files  it 
off-line  into  the  Output  Tape*for  special  postprocessor  analysis . (See 
Figure  28.)  It  also  records  the  station  and  resource  utilization 
statistics.  Below  is  a list  of  these  statistics  and  their  definitions: 
(a)  Case  Statistics 

(i)  COSTC:  Total  cost  for  service  of  the  case,  including 

the  cost  of  a long  search  and  the  cost  to 

vector  to  the  expected  location.  In  the  case 

of  a single  resource  or  multi -resource  case 

*If  opted  by  user. 
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requiring  no  search,  the  cost  of  servicing 
the  case  on  scene  for  a particular  need  is 
not  included.  Cost  is  calculated  in  this  fashion 
because  the  on-scene  portion  of  a case  (or  need) 
other  than  search  is  relatively  resource  in- 
dependent. The  philosophy  is  somewhat  different 
in  selecting  a resource  for  a long  search.  For 
these  cases , the  cost  of  covering  a desired 
amount  of  search  miles  varies  widely  for 
different  resource  types.  Therefore,  this 
cost  includes  the  cost  of  performing  the 
search  as  well  as  the  cost  of  vectoring  to 
the  scene. 

The  cost  of  the  case  is  accumulated  over  all  interrupts.  Note 
also  tha£,  regardless  of  the  cost  option,  COSTO  (i.e.,  the 
operating  cost  per  hour  or  cost  ranking)  selected,  COSTC  is 
calculated  as  above. 


(ii) 

TSVC : 

The  total  time  the  case  spends  in  the  system  from 
its  arrival  to  its  completion. 

(iii) 

TQUE: 

The  total  time  the  case  spends  in  the  queue  accu- 
mulated each  time  the  case  is  placed  in  the  queue. 

(iv) 

NQUE: 

The  total  number  of  times  a case  is  queued. 

(v) 

TQUE1: 

The  elapsed  time  spent  in  a queue  prior  to  the 
first  arrival  of  a resource  to  the  scene. 
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(vi)  TWAIT : 


(vii)  CNRES : 


(viii)  NOINT: 

(ix)  TINT: 

(x)  PRI : 


(xi)  REA: 


(xii)  RESA(i) : 


The  elapsed  time  prior  to  first  arrival  of  a 
resource  on  scene.  This  is  usually  equal  to 
the  time  it  takes  the  resource  to  vector  to  the 
scene  Tvec(k)  plus  the  time  the  client  spent  in 
queue,  TQUE1,  except  if  the  case  was  interrupted. 
The  total  number  of  resources  serving  the  case, 
including  the  resources  assigned  after  the 
case  has  been  interrupted. 

Number  of  times  the  case  is  interrupted. 

Total  time  the  case  is  in  the  interrupted  state, 
waiting  in  the  queue. 

Final  priority  of  the  case;  priority  is  a 
function  of  severity  level,  which  is  re-evaluated 
during  the  service  of  the  case  and  is  updated 
if  the  case  is  placed  in  queue,  or  in  ONSCN. 

The  reason  the  case  was  first  placed  in  a queue. 

The  case  can  be  queued  for  either  of  two  reasons: 

a.  If  there  are  no  capable  resources  available 
at  the  primary  and  adjacent  (dependent 

on  the  resource  assignment  policy)  avail- 
able at  the  time  the  case  enters  the  system;  or 

b.  If  service  is  interrupted  due  to  a case  of 
higher  priority. 

For  each  i^  need  of  the  case,  the  first  resource 
serving  that  need  is  recorded. 


-136- 


(b)  Station  and  Resource  Statistics 


Statistics  are  collected  in  OPSIM  relative  to  stations  and  their 
resources . District  level  aggregates  and  averages  are  also  derived 
and  offered  as  the  Standard  Output,  and  are  printed  by  the  Report 
Generator . 

For  each  resource,  1,  in  the  inventory,  the  average  utilization 
index  UTIL(l),  is  calculated  as  the  ratio  of  the  total  number  of  hours 
throughout  the  simulation  the  resource  was  busy  to  the  total  time 
simulated. 

For  each  station  in  the  district  the  average  utilization  index 
is  calculated  for  each  shift.  (The  simulation  allows  for  a maximum 
of  eight  shifts  relative  to  a week  within  a given  peak  or  non-peak 
season.  These  shifts  correspond  to  the  manning  levels  of  the  district. 
If,  for  example,  the  manning  levels  change  at  given  times  of  the  day,thes 
times  dictate  the  shifts.)  The  average  utilization  index  per  station  i,a 
per  shift  R,USHF  (i,R),  is  calculated  as  the  ratio  of  the  total  number 
of  resource  hours  used  to  the  total  potential  number  of  resource 
hours  available  during  that  shift,  across  the  resources  attached 
to  station,  i. 

Certain  aggregate  statistics  are  found  for  each  station  i in  the 
district.  These  include: 

(i)  The  number  of  cases  served  by  station  i:  NCAS(i). 

(ii)  The  number  of  needs  served  by  station  i:  NEEDS  (i) . 

(iii)  The  number  of  interrupts  at  station  i:  NINTR(i) . 

(iv)  The  number  of  times  a standby  crew  is  called  at  station  i: 
NSTBY(i)  . 
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(v)  The  number  of  times  a standby  crew  was  called,  but 

not  used  at  station  i:  UNPRO(i).  A time  delay  exists 

between  call-up  and  the  time  at  which  the  standby  arrived 
at  the  station.  Therefore,  a waiting  case  could  be  served 
by  a manned  resource  which  became  available  during  this 
delay  time. 

Three  levels  of  failures  are  defined  and  are  recorded  for  each 

station.  These  include: 

(i)  The  number  of  cases  which  came  into  station  i where  there 
was  no  capable  resource  in  the  district  to  serve,  or 
failure  type  A FAILl(i). 

(ii)  The  number  of  cases  where  was  no  capable  resource  at  the 
primary  (and  adjacent),  or  failure  type  B,  FAIL2(i). 

(iii)  The  number  of  cases  where  the  case  was  not  served  within 
tolerance  FAIL3(i). 

Average  wait  time  at  a station  is  also  calculated  along  with 
average  utilization  index.  Average  wait  time  is  the  arithmetic  average 
of  the  values  of  TWA1T  for  those  cases  arriving  at  that  station. 

Average  utilization  index  at  a station  i, USE(i),  is  calculated 
as  the  ratio  of  the  resource  hours  used  to  the  potential  resource 
hours  at  station  i. 

Any  exceptional  cases  are  included  as  automatic  output,  and 
their  parameters  are  also  output.  These  include  any  cases  for  which 
no  resource  can  satisfy  a need  of  the  case. 
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A district  summary  is  provided  as  part  of  the  Standard 
Output  and  includes : 

(i)  The  total  time  simulated. 

(ii)  The  total  number  of  cases  that  occurred  during  the 

the  total  simulated  time. 

(iii)  The  total  number  of  cases  that  were  completed. 

(iv)  The  total  number  of  cases  where  failure  type  A occurred: 

2 FAX LI (i) . 

1 

(v)  The  total  number  of  cases  where  failure  type  B occurred: 

2 FAXL2 (i) . 
i 

(vi)  The  total  number  of  cases  where  failure  type  C occurred: 

? FAILS (i) . 

i 

(vii)  The  average  utilization  index  across  the  district  is  cal- 
culated as  the  ratio  of  the  total  resource  hours  used  to 
the  total  potential  number  of  resource  hours  in  the  dis- 
trict, throughout  the  duration  of  the  simulation. 

(viii)  For  each  shift,  the  average  utilization  index  across  the 
district  is  calculated  as  the  ratio  of  the  total  resource 
hours  used  to  the  total  potential  resource  hours  in  a 
given  shift. 

(ix)  The  total  number  of  needs  served  and  the  total  number 
of  interrupted  needs  are  aggregated  for  the  district. 

(x)  The  average  time  any  case  waits,  taken  as  the  arithmetic 
average  of  the  TWAIT  values  across  all  the  cases , is 
also  calculated. 
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(xi)  Finally,  aggregates  of  the  total  number  of  standbys, 

Z NSTBY(i)  and  total  number  of  unproductive  standbys 

X 

Z UNPRO(i)  are  calculated  for  the  district, 
i 

The  reader  is  referred  to  the  program  listings*  Report  Generator 
Section,  for  a layout  of  these  statistics. 

After  the  collection  of  statistics  is  completed  on  each  case, 
and  each  case’s  contribution  to  the  station  and  resource  statistics 
recorded,  the  resource  is  made  available  to  those  cases  awaiting 
sendee  in  the  queue.  EXQ  examines  the  queue  for  a waiting  case  at 
the  primary  station  (and  adjacents  depending  on  the  resource  assign- 
ment policy).  (See  Figure  28.) 

If  the  resource  is  capable  and  operational  and  a crew  is  available, 
the  resource  is  assigned  to  the  highest  priority  waiting  case.  If 
there  are  no  waiting  cases  that  this  resource  can  serve,  the  resource 
is  vectored  home.  Crew  availability  is  assessed  in  exactly  the  same 
fashion  as  if  the  resource  were  at  its  home  station,  that  is,  the 
changes  in  crew  manning  levels  over  the  day  are  taken  into  account. 

HOME  is  called  at  the  time  the  resource  has  arrived  at  its  home 
station.  Here  the  status  of  the  resource  and  crew  is  updated  to 
idle . 

If  the  need  of  the  waiting  case  to  be  serviced  is  a search  need, 
the  remaining  endurance  of  the  resource  is  examined.  The  time  to 
vector  to  scene  is  compared  against  SUNSET  of  that  day  or  SUNRISE  of 
the  next  day.  That  is,  if  the  resource  can  arrive  before  SUNSET  it 

*Contained  in  Appendix  B of  this  series,  NBS  Report  # 10436. 
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is  vectored.  If  the  resource  can  arrive  after  SUNRISE  of  the  next 
day,  then  he  is  vectored.  Vectoring  takes  place  only  if  the 
resource  is  capable,  has  sufficient  endurance,  and  an  available 
crew.  Otherwise,  the  case  remains  in  the  queue.  Recall  that 
queued  search  cases  are  examined  at  SUNRISE  - X hours. 

A special  subroutineCSTNBY)  examines  waiting  cases  at  the  time 
a standby  crew  arrives  to  the  station.  The  same  logic  of  EXQ  relative 
to  the  resources  is  included,  but  a crew  is  already  available  --  only 
the  resources  capability,  endurance, etc. , need  be  assessed. 
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4.  POSTPRO  - The  Postprocessor  of  SARSIM 


The  Service  Subroutine  of  OPSIM  automatically  produces  the 
OPSIM  STANDARD  OUTPUT*  and  may  also  be  instructed  to  generate  an 
OUTPUT  CASE  TAPE  for  specialized  data  analyses  in  the  Postprocessor 
(POSTPRO) . Prepackaged  data  retrieval  programs  such  as  Quick 
Query  — ^ are  currently  used  to  provide  these  specialized  outputs.  The 
Quick  Query  program  was  developed  by  C.A.C.I.  and  is  compatible  with  the 
SIMSCRIPT  language  in  which  OPSIM  is  programmed. 

A typical  request  might  consist  of  the  aggregation  of  all  weekend 
cases  which  waited  more  than  some  specified  number  of  hours  and  whose 
severity  level  was  initially  at  some  given  level. 

The  OPSIM  STANDARD  OUTPUT  provides  statistics  with  reference 
to  resource  types*  stations*  and  the  district  as  a whole.  In  addition, 
data  are  printed  out  on  any  exceptional  cases , that  is  9 cases  which 
cannot  be  served  due  to  lack  of  a capable  resource  in  inventory  at 
the  primary  or  adjacent  stations  (failure  types  A and  B) * or  an 
interrupted  air  escort  case. 

Any  changes  to  the  input  conditions  are  also  listed.  These  changes 
are  relative  to  a given  base  run  and  include  the  following: 

(1)  Any  changes  to  the  station  to  include  additions  or  deletions 
of  stations  to  the  district;  and/or  changes  in  the  station 

I/  ' 'Quick  Query  User’s  Manual  for  Economic  Development  Administration", 
Working  Paper,  by  Consolidated  Analysis  Centers,  Inc.,  C.A.C.I., 
January  1970. 
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attributes,  such  as  the  type  and  number  of  resources;  or 
the  shift  levels. 

(2)  Any  changes  in  the  resource  types  in  the  district  inventory 
such  as  additions  or  deletions  of  types;  attribute  changes 
of  each  type,  for  example,  the  capability  of  a given  type. 

(3)  Any  changes  in  the  resource  deployment  at  any  station, 
existing  or  new. 

(4)  Any  changes  to  the  crew  manning  levels,  new  or  existing. 

In  addition  to  changes,  the  user  input  options  relative  to 

the  PREPRO,  OPSIM  and  POSTPRO  are  delineated,  so  that  the  simulation 
exercise  can  be  uniquely  identified. 

Completed  cases  are  filed  on  the  Output  Case  Tape.  The  POSTPRO 
operates  on  this  tape,  as  an  option  to  the  user,  and  generates 
additional  statistics  of  interest  to  the  user.  This  option  provides 
flexibility  of  output  reporting  at  the  management  and  analyst  levels. 
Having  a file  of  completed  cases,  with  both  the  input  information  and 
the  status  at  completion, allows  for  a wide  variety  of  queries  to  be 
processed. 

For  each  case,  the  following  inf  ormation  is  hept . 

(1)  OPFAC:  The  historical  primary  station  of  the  case. 

Note,  this  primary  is  assigned  in  PREPRO,  and  updated  in  OPSIM.  The 
updated  value  is  P,  the  primary  station. 

(2)  NOCAS:  Number  of  case. 
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(3)  IDLOC:  District  in  which  the  case  took  place. 

(4)  OCCUR:  Date  and  time  of  case  arrival  to  the  system 

(5)  BOX:  An  indicator  showing  whether  the  case  occurred  during 

the  weekday  or  on  a weekend  and  either  during  the 
day  or  night. 

(6)  FPRI:  The  priority  of  the  case  as  it  enters  the  system. 

(7)  MMM:  The  number  of  tow  or  escort  needs 

(8)  NNN:  The  total  number  of  needs  except  long  search  and 

tow  or  escort. 

(9)  GAMMA:  Degree  of  non  parallel  service. 

(10)  AIR:  Air  temperature  at  time  of  the  case. 

(11)  OFSHR:  Distance  off-shore. 

(12)  VIS:  Visibility 

(13)  WIND:  Wind  Force 

(14)  SWELL:  Sea  height 

(15)  L:  Length  of  distressed  vessel 


(16) 

POB: 

Number  of  people  on  board  distressed  vessel. 

(17) 

SIS: 

Number  of  resources  in  long  search 

(18) 

S2S: 

Sho^t  search  code 

(19) 

TSM: 

Total  search  miles  on  case 

(20) 

UTYPE: 

Type  of  distressed  unit 

(21)  VALUE: 

Value  of  distressed  unit 

(22) 

XCX: 

Original  Case  location 
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(23)  YCY:  Original  Case  location 

(24)  XC:  Case  location  (Updated) 

(25)  YC:  Case  location  (Updated) 

(26)  STAIN:  Reassigned  primary  station 

(27)  CNRES:  Number  of  resources  involved  in  a case 

(23)  PRI:  Final  case  priority 

(29)  REA:  First  reason  case  was  queued. 

(30)  COSTC:  Total  cost  to  serve  the  case 

(31)  ITOL:  Indicator  relative  to  case  being  served  within  tolerance 

(32)  NOINT:  Case  interrupt  count 

(33)  NQUE:  Number  of  times  case  was  queued 

(34)  TINT:  Total  time  in  interrupt  status  in  the  queue. 

(35)  TQUE:  Total  time  case  spends  in  queue. 

(36)  TQUE1:  Time  case  spends  in  queue  prior  to  first  resource 

arriving  to  scene. 

(37)  TSVC:  Total  time  case  spends  in  system 

(38)  TWAXT:  Time  between  case  occurrence  and  arrival  of 

first  resource 

(39)  NEED(i):  Need  of  a case 

(40)  OST(i):  Time  on  scene  of  Need  (i) 

(41)  DELTA (i ) : Delay  of  next  resourse  arrival,  multi-need  case. 

(42)  RESA(i):  Resource  assigned  to  serve  Need  (i) 
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When  the  case  includes  search  and  or  tow  or  escort, 

RESA(i)  is  expanded  to  include  the  resources  assigned  to  serve  these 

needs  as  well. 

Using  the  Case  Tape,  with  the  above  attributes,  the  user  can 
make  specialized  requests.  For  example,  an  aggregation,  or  printout 
of  all  weekend  cases  which  waited  more  than  a given  amount  of  time 
and  had  a given  input  severity  (or  priority)  can  provide  the  user  with 
some  insight  as  to  whether  his  resources  are  strategically  placed, 
or  perhaps  his  manning  levels  need  alteration.  The  added  information 
of  wait  time  broken  out  by  severity  level  enhances  the  Standard  Output 
relative  to  average  station  TWVIT  and  stand  by  call-ups. 
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APPENDIX  A:  Inter-District  Assignment  and  Service 

Subroutine  (IDASS)  of  OPSIM 

I . Introduction 

As  originally  conceptualized,  a special  submodel  was  developed 
to  model  the  availability  of  the  C-130  aircraft  to  service  cases  within 
its  long-ranged  capability.  Simulation  of  cases  which  occurred  his- 
torically external  to  the  district  were  to  be  simulated  in  IDASS  and 
served  only  by  a C-130.  Those  that  occurred  inside  the  district  could 
be  served  by  any  capable  resource,  perhaps  a C-130,  the  selection  being 
dependent  on  the  cost  option,  tje  statis  pf  tje  respirces.  the  environ- 
mental conditions , and  the  case  parameters . 

An  improved  approach  to  handling  the  simulation  of  those  cases 
served  by  the  C-130  has  since  replaced  IDASS.  This  discussion  is 
in  the  main  body,  including  the  special  preparation  required  to 
develop  the  case  parameters  for  C-130  cases.  The  air  station  at 
which  the  C-130’s  are  based  is  included  in  the  list  of  primary  stations. 
To  prevent  any  other  resource  type  from  responding  to  the  out  of  the 
district  C-130  cases,  this  air  station  has  no  adjacent  stations. 

The  effort  required  for  designing  IDASS  and  developing  the  computer 
program  was  well  spent  in  that  it  proved  to  be  the  pilot  effort  in 
the  application  of  the  selected  computer  language,  SIMSCRIPT  to  SARSIM. 
Since  IDASS  is  a functioning  model,  but  not  included  in  the  current  con- 
ceptualization of  SARSIM,  a discussion  is  presented  in  this  appendix. 

SARSIM  is  basically  designed  to  be  exercised  on  the  district 
level.  Those  resources  assigned  to  each  district  are  normally  called 
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upon  to  serve  those  cases  that  occur  in  the  district.  Special  attention 
is  given,  however,  to  the  C-130  since  some  of  its  characteristics,  such 
as  its  long  range  potential  and  faster  response,  have  resulted  in  its 
frequent  use  on  an  inter-district  basis.  Such  employment  of  resources  is 
an  exception  to  the  district  boundary  assumption.  It  is  important, 
therefore,  to  model  the  availability  of  this  resource  to  serve  cases  in 
the  district  being  exercised  simultaneously  with  all  other  districts 
using  these  C-130's.  The  major  objective  of  SARSIM,  as  it  is  presently 
envisioned,  is  to  measure  the  sensitivity  of  SAR  effectiveness  within 
each  district  by  varying  such  factors  as  resource  allowance,  deployment, 
and  case  load.  IDASS  provides  a means  of  including  C-130’ s as  an 
integral  part  of  any  CONUS  coastal  Coast  Guard  district  by  modeling 
the  availability  of  a C-130  to  service  cases  on  an  inter-district 
basis , concurrently  with  the  normal  work  load  of  the  district  under 
investigation.  Therefore,  the  Coast  Guard  manager  has  at  his  dis- 
posal a tool  to  measure  the  effects  on  each  district  and  on  each 
coast,  of  varying  the  number  of  C-130 ’s,  their  work  load  and  de- 
ployment. 

II.  Background  and  Assumptions 

The  Lockheed  C-130  is  four  engine,  fixed  wing  aircraft  which  is 
capable  of  proceeding  1200  NM  at  290  knots  to  the  site  of  a SAR  inci- 
dent, remain  on  scene  for  21/2  hours  and  return  to  the  point  of  origin 
with  adequate  fuel  reserve.  On  the  average,  its  total  airborne  time 
is  approximately  12  hours. 


C-130  SAR  coverage  for  CONUS  is  currently  provided  by  'two 
Coast  Guard  air  stations:  San  Francisco,  California.,  (12th  district) 

for  the  West  coast;  and  Elizabeth  City,  North  Carolina,  (5th  district) 
for  the  East  coast.  The  East  coast,  insofar  as  C-130  availability  is 
concerned,  is  comprised  of  1st,  3rd,  5th,  and  7th  Coast  Guard  Districts. 
For  the  West  coast,  C-130's  are  available  to  the  11th,  12th,  and  13th 
Coast  Guard  Districts. 

Time  of  case  notification  is  considered  time  of  assigned  resource 
departure.  No  warm-up  or  communication  delays  have  been  considered 
in  the  simulation  concept  at  this  point.  These  time  delays  can  be 
incorporated  in  the  model  at  a later  date.  Provisions  for  crew  rest 
and  refueling  have  been  included  for  those  flights  exceeding  12  hours, 
and  for  certain  interrupt  situations.  All  flights  between  the  1st 
and  7th;  or  3rd;  or  8th;  districts  on  the  East  coast  assume  an  enroute 
refueling  delay  of  one  hour.  Likewise,  a similar  delay  appropriate 
for  the  West  coast  is  to  be  included. 

The  number  of  C-130's,  i.e.,  the  allowance,  available  for  SAR 
missions  is  adjusted  to  account  for  the  effects  of  maintenance,  crew 
manning  levels,  and  non -SAR  functions. 

III.  Special  Preprocessor  Required  for  IDASS 

Before  the  logic  of  IDASS  can  be  discussed,  it  is  necessary  to 
discuss  the  special  processing  required  of  the  C-130  historical  data. 

For  each  coast,  a C-130  case  file  is  prepared  by  examining  the  his- 
torical SAR  workload  at  Elizabeth  City  (or  San  Francisco)  and  re- 
taining those  historical  C-130  cases.  (From  this  point,  only  the 


East  coast  will  be  addressed  to  facilitate  illustration  of  the 
techniques  in  this  special  processing.) 

The  historical  C-130  case  load  is  analyzed  and  the  relevant  dis- 
tributions and  parameters  developed.  See  Figure  A1  for  the  flow  of 
these  operations.  The  PGP,  program  to  calculate  case  parameters,  can 
be  modified  to  develop  these  parameters;  or,  since  there  are  relatively 
few  of  these  cases  , it  may  be  preferable  to  prepare  these  cases 
manually.  A distribution  of  time  on  scene  also  must  be  developed  for 
input  to  IDASS.  The  Demand  Generator  can  likewise  be  modified  to 
generate  the  C-130  case  load.  All  C-130  cases  carry  an  extra  attribute, 
the  district  where  the  case  occurred.  An  additional  processing  step 
is  therefore  required  to  determine  the  district  within  which  the 
case  occurred. 

The  output  of  this  special  processing  is  a C-130  case  load  with 
the  district  identified  where  each  case  occurred.  This  output  is  then 
merged,  on  date  and  time  of  occurrence,  with  the  Demand  Tape  for  the 
district  to  be  exercised.  The  final  composite  merged  tape  becomes 
the  input  to  the  Operational  Simulator. 

IV.  Required  Inputs  to  Operate  IDASS 

The  required  inputs  for  operating  IDASS  are  similar  to  those 
described  in  the  section  in  SRAS.  The  user  inputs  applicable  to  this 
subroutine  include  the  station  inputs  describing  the  "equivalent" 
number  of  C-130 's  attached  to  the  station  for  SAR  purposes  with  crew 
manning  level  and  maintenance  factors  inherent  in  this  number.  One 
more  input  required  for  IDASS  is  a matrix  providing  the  expected  vector 


time  to  arrive  on  scene  between  each  pair  of  districts  and  between 
Elizabeth  City  and  each  district.  This  matrix,  AOST  (i,  j)  describing 
the  average  time  of  arrival  to  a case  in  district  i,  from  district 
j,  includes  the  time  required  to  refuel,  if  required.  An  illustration 
of  AOST  (i,  j)  matrix  is  presented  in  Table  Al.  The  entries  shown  in 
each  AOST  (i,  j)  cell  represent  the  C-130  flight  hours  to  vector  to  or 
from  the  weighted  centroid  in  each  of  the  four  East  Coast  districts 
and  Elizabeth  City.  This  weighted  centroid  is  derived  from  an  analysis 
of  the  historical  data  determining  a specific  latitude  and  longitude 
within  each  district  as  the  one  most  representative  of  where  the 
average  C-130  case  occurred  in  that  particular  district. 

Case  Location  versus  Time  to  Vector  to  Scene 


(Hours) 

C-130  Location  "j" 


To  District 

1 

3 

5 

7 

E City 

From 

District 

1 

.5 

1 

2 

6* 

3 

3 

1 

.5 

1 

5* 

1 

5 

2 

1 

.5 

3 

1 

7 

6* 

5* 

3 

.5 

3 

E City 

3 

1 

1 

3 

0 

*Assumes  refuel  enroute 

TABLE  Al:  AOST  (i,j) 


V.  IDASS  Logic 

The  interface  between  the  Preprocessor  and  the  Operational 
Simulator,  the  OPSIM  EXEC,  determines  which  resource  assignment 


subroutine  to  enter.  As  each  case  arrives  to  the  system,  the  district 
in  which  it  occurred  is  examined.  Control  is  passed  to  IDASS  for 
those  cases  outside  of  the  district  undergoing  exercise.  Note  that 
a case  which  historically  was  a C-130  case  occurring  within  the  dis- 
trict being  exercised  is  served  in  the  normal  fashion,  as  a single 
resource  or  search  case.  Thus,  the  case  has  an  opportunity  to  be 
handled  by  any  capable  resource  including  a C-130.  Similarly,  cases 
emanating  from  the  work  load  not  historically  associated  with  C-130’s 
are,  of  course,  now  eligible  for  a C-130  assignment  via  SRAS,  MRAS 
or  SASS. 

The  flow  of  operations  within  IDASS  is  illustrated  in  Figures  A2 
and  A3  . Briefly,  IDASS  simulates  the  assignment  of  a C-130  to  the 
case  and  the  service  of  that  case.  A resource  is  assigned  to  a 
case  if  the  resource  is  idle  at  the  time  of  arrival  of  the  case  to 
the  system,  or  a resource  is  on  a lower  priority  case  and  can  be 
interrupted  to  handle  the  new  arrival  to  the  system.  Otherwise,  the 
case  must  wait  in  a queue  for  a resource  to  become  idle  and  available. 
Step  1:  Refer  to  Figure  A2.  Accessing  the  status  of  each 

C-130,  the  first  step  is  to  determine  if  there  is  an  idle  resource 
at  the  air  station  (e.g. , Elizabeth  City).  If  so,  control  is 
passed  to  ASIN  1 which  simulates  the  service  of  the  case  and  the 
scheduling  of  crew  rest  and  refueling,  if  required. 

Within.  ASIN  1,  the  total  on  scene  time,  TOS,  is  attained 
via  Monte  Carlo  and  the  vector  time,  TVEC,  is  retrieved  from  the 
matrix  AOST  (i,  j);  the  sum  of  TOS  and  (TVEC)  is  added  to  OCCUR, 


the  current  simulated  clock  time,  to  determine  the  Expected 
Idle  Alpha  Time  (ELAT).  If  the  difference  between  EIAT  and  OCCUR 
exceeds  the  maximum  12  hour  endurance  of  the  C-130,  crew  rest 
and  refueling  is  simulated;  and  additional  sorties  are  required  to 
service  this  case. 

Control  is  passed  to  routine  IS  which  calculates  the  client 
service  time  (CST) , or  the  elapsed  time  the  client  is  undergoing 
service  (including  vectoring)  by  the  Coast  Guard.  In  addition, 
the  resource  service  time  (RST)  is  also  calculated.  CST  is  the 
sum  of  the  total  on  scene  time,  TOS;  the  time  to  vector  to  the 
scene,  TVEC;  and  additional  TVEC's  to  and  from  the  scene  for 
those  cases  requiring  additional  sorties.  RST  is  the  sum  of  CST 
and  the  time  required  to  return  to  Bravo-Zero  status  at  the  home 
station  (e.g.,  Elizabeth  City).  EIAT  becomes  the  sum  of  the 
time  of  departure  of  the  resource  and  the  client  service  time, 

CST. 

If  no  C-130 ?s  are  idle  at  the  station,  step  2 is  executed. 
Step  2 : An  attempt  is  made  to  assign  an  idle  C-130  which  is 

returning  to  the  air  station  (e.g.,  Elizabeth  City).  If  there 
are  idle-retuming  C-130 's  control  is  passed  to  ASIN  2.  See 
Figure  25. 

Within  ASIN  2,  the  closest  ’’idle- returning"  C-130  to  the 
case  is  selected.  The  remaining  process  is  similar  to  ASIN  1. 

If  there  are  no  idle  resources  returning  to  the  air  station,  then 
control  passes  to  step  3. 


Step  3;  If  the  case  is  of  a higher  priority  than  other  cases 
currently  being  served  in  the  system,  then  the  lowest  priority 
case  is  interrupted  and  control  passes  to  AS IN  3.  The  interrupted 
case  is  placed  in  the  appropriate  priority  queue  and  awaits  addi- 
tional service  on  a first-in,  first-out  basis.  Subroutine  QUEUE 
places  the  interrupted  case  in  the  queue.  (See  the  SRAS  des- 
cription for  an  explanation  of  QUEUE.)  This  new  case  is  treated 
similarly  as  a case  in  ASIN  2.  If,  however,  the  new  case  is  of 
a lower  priority  than  those  cases  already  undergoing  service,  it 
is  placed  in  tire  appropriate  queue  to  wait  for  a C-130  to  become 
available,  by  calling  subroutine  QUEUE.  When  a C-130  becomes 
idle,  subroutine  EXQ  (see  SS  description)  examines  all  queues  to 
determine  which  case,  if  any,  should  be  served  by  this  resource. 

VI . Special  Output  Reporting  for  IDASS 

Since  IDASS  is  a macro -level  simulation  of  the  availability  of 
C-130 to  serve  inter-district  cases,  as  compared  to  the  simulation 
of  district  cases,  only,  certain  aggregate  statistics  are  kept.  These 
include:  total  number  of  C-130  cases;  total  client  service  time; 

total  resource  service  time;  total  number  of  C-130  flights  exceeding 
12  hours.  For  each  queued  or  delayed  case,  its  time  spent  in  the 
queue,  its  reason  for  delay,  and  its  identification  are  recorded. 

After  each  district  has  been  exercised  under  similar  conditions, 
and  the  results  integrated,  the  Coast  Guard  manager  will  be  capable  of 
evaluating  the  utilization  of  C-130' s for  the  coastal  SAR  mission. 


Special  Pre-Processing  for  IDASS 
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Figure  Al: 


Figure  A2: 


IDASS;  ASIN1;  IS 


Figure  A3:  ASIN  2;  ASIN  3 
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Appendix  B: 


Glossary  of  Terms 


A:  Adjacent  Station 

AIA:  District  in  which  Case  occurred.  See  IDLOC 

AIR:  Air  temperature  at  time  of  the  Case.  See  B6. 

AOST(i,j):  Vector  time  for  IDASS  from  i to  j . 

A3:  Number  of  Case.  See  NOCAS. 

A4:  Month  and  year  station  was  notified. 

B16:  Type  of  distress  area 

BETA:  Length  in  nautical  miles  of  1 degree  of  longitude  at  district  origin 

B3:  People  on  board  distressed  unit 

B5:  Value  of  property  involved 

B6:  Air  temperature  at  time  of  the  Case.  See  AIR. 

C (K) : Cost  for  each  capable  resource  K 

CL:  Crew  Level 

Dl:  Assisting  resource  type 

D3:  Time  resource  was  underway 

D4:  Time  resource  arrives  on  scene 

D4FRST:  Time  resource  arrives  on  scene  time  and  completes  search, 

D6:  Search  Lime  for  a single  resource 

D6T0T:  Total  search  time  for  a Case 

D8:  Total  elapsed  time  underway  on  Case 

D9:  Number  of  sorties  for  a resource 

Dll:  Assistance  rendered  to  personnel 

D12:  Primary  assistance  rendered  to  property 
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D13:  Secondary  assistance  rendered  to  property 

DD:  Distance  and  destination  client  is  to  be  towed  or  escorted 

DLAY(L):  Time  to  get  underway  for  resource  type  L 

DRS:  Distribution  for  severity  level  change 

A(i):  Proportion  of  time  into  case  completion  resource  i arrived  on  scene 

EIAT:  Estimated  idle  alpha  time  - IDASS 

END (L) : Endurance  in  hours  for  resource  type  L 

EOF:  End  of  file 

FLAG:  Indicates  if  the  (i-l)st  resource  is  waiting  on  the  ith  resource 

FPRI : Priority  of  the  Case  as  it  enters  the  system.  Determined  in 

PREPRO.  See  S. 

FRST:  First  resource  on  scene  begin  serving  a need 

y:  Degree  of  non-parallelism  of  a multi -resource  Case 

HU:  Hookup  time  distribution 

IDELTA:  Step  increase  of  the  Case  priority 

XDLOC:  District  in  which  Case  occurred.  See  AIA. 

INTRAP:  Overide  RAP  switch 

IPC:  +1  Severity  increase 

-1  Severity  decrease 

0 No  severity  change 

k:  Index  for  resources 

K:  Number  of  capable  resources. 

KS:  Number  of  re-evaluations  to  be  made  of  the  case  severity,  a 

user  input 

L:  Index  for  resource  types 

LAST:  Time  last  resource  left  scene  after  searching  and  serving  need 
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Aij : Arrival  rate,  ith  hour  of  jth  time  period 

LVTM:  Time  at  which  resource  i completes  search,  if  any,  and  servicing 
m:  Number  of  tow  or  escort  resources.  See  MMM 

MILES:  Distance  off-shore.  See  OFSHR 

MINC1:  Minimum  time  of  notification  of  the  Case.  See  OCCUR  and  A4 

MMM:  Number  of  tow  or  escort  resources.  See  m 

MR:  Mil ti- resource 

n:  Number  of  needs  except  search  and  tow.  See  NNN 

NN:  Total  number  of  needs  plus  hand-off  tows;  NN  = n+m-1,  when  m > 0 

NN  = n , when  m = 0 

NNN:  Number  of  needs  except  search  and  tow.  See  n 

NEED:  Specific  need  of  a Case 

NEED(i):  Need  being  served  by  ith  resource 

NH:  Night  hours  if  tes  exceeds  the  number  of  daylight  hours 

NOCAS:  Number  of  the  Case.  See  A3 

NOINT:  Number  of  interrupts  of  the  Case 

NOTIF:  Notification  time  of  Case 

NQUE:  Total  number  of  times  a Case  is  queued 

OC(L):  Operating  cost/hour,  for  resource  type  L 

OCCUR:  Date  and  time  of  Case  arrival  to  the  system.  See  A3  and  A4 

OFSHR:  Distance  offshore.  See  MILES 

Origin  Latitude : ) 

<>  district  origin 
Origin  Longitude : J 

P:  Primary  station  as  defined  in  OPSIM 
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PDC(DAY):  User  input,  percentage  of  SM(i)  desirable  to  achieve, by  each 

search  resource,  for  the  DAYth  day  into  the  search 

PR(k):  Percentage  of  SM(i)  completed  before  SUNSET  or  TOLS(S)  by  each 

of  the  K capable  resources 

PRI : Priority  of  the  Case 

PRTSM  (i) : Fractional  split  of  TSM  as  a function  of  SI 

RLSfk):  Resource  leave  scene  = TIME  + t (k)  + t (i) 

REA(CASE) : Reason  case  was  first  placed  in  queue 

RNSEED:  Random  number  seed 

ROSQc):  Time  resource  arrives  on  scene  = TIME  + t c(k). 

RST:  Resource  Service  Time  - IDASS 

RAP(i):  Resource  assignment  policy 

S:  Severity  of  the  Case.  See  FPRI  and  PRI 

SI:  Average  number  of  search  resources;  operating  in  parallel 

S2:  j 0 No  short  search 

"S  1 Short  search  by  assigned  resource 
I 2 Short  search  by  additional  resource 

SFLAG:  Indicates  first  resource  assigned  to  the  search  Case 

SM(i):  Number  of  search  miles  a search  resource  attempts  to  complete 

S0A1  (L) : Speed  of  advance  for  resource  type  L during  weather  condition  1 

S0A2 (L) : Speed  of  advance  for  resource  type  L during  weather  condition  2 

S0A3(L):  SOA  when  searching,  for  resource  type  L 

SR:  Single  resource 

STAND:  Station  number  as  defined  in  PREPRO 

SUNRISE:  User  input  time 

SUNRISE  LIST:  A list  of  held-over  search  cases  which  are  examined  at 

SUNRISE  - x 
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SUNSET:  User  input  time 

SVAR:  Severity  increase  factor  for  short  search 

t : Elapsed  time  on  scene  serving  needs 

tes:  Elapsed  time  spent  searching  only 

t^(L) : Refuel  time,  for  resource  type  L 

t^:  Tow  hookup  time  (or  escort  delay  time) 

TIME:  Current  Simulated  Clock  Time 

TOL(S):  Tolerance  for  non- search  use  at  severity  level  S 

tg(i):  Time  spent  on  scene  searching  for  sortie  i 

tos(i):  On  scene  time  for  serving  need  i 

tos:  Hookup  time  plus  tow  time 

TOS:  Time  on  scene  for  IDASS 

TOWTIME (i) : Tow  time  for  the  ith  towing  resource;  or  escorting  resource 

TOLS(S):  Search  tolerance  time  at  severity  level  S 

tret(i):  Time  to  return  to  homeport 

t : Towspeed 

tstQ0:  Time  spent  searching  (total)  > for  capable  resource  k 

TVEC:  Time  to  vector  to  case  IDASS 

Tvec00:  Time  it  takes  capable  resource  k to  vector  to  expected  search 

area 

TSM:  Total  search  miles  on  a case 

x:  The  hours  before  SUNRISE  when  held-over  search  cases  are  examined 

for  resource  assignment  (user  input) 

Case  Location  in  statute  miles 


B-5 


Appendix  C. 


Glossary  of  Flowchart  Symbols 


Control  is  passed  to  a 
subroutine  at  the  simulation  time,  STIME 
Control  is  returned  to  main  program  at 
present  time,  TINE 


f 

! 


© 

R^rj) 


IRET 


Connector 


Return  to  main  program 


Return  to  main  program 


( ) 


Control  is  passed  to  a 
subroutine  at  the  present 
time,  TIME 
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Subroutine  called  at 
present  time,  TIME 


Merge  information  according 
to  a given  order 


